>>> 8) Any RAM that is not immediately usable by the OS should not be >>> reported as "usable RAM" in the memory map. An example of this is the >>> "ACPI reclaimable" area (which is RAM that isn't usable until the OS >>> has finished using the ACPI tables). RAM used to store the multi-boot >>> information, RAM used to store the "kernel" and RAM used to store any >>> modules should be treated in the same way. I suggest using "area type >>> 0xFFFFFFFE = RAM used for multi-boot information" and "area type >>> 0xFFFFFFFD = RAM used for kernel/modules". This makes it much easier >>> to write a kernel's early initialisation code, because it can use RAM >>> without worrying about trashing data that is needed by the kernel/OS >>> later. >>> >> kernel should know itself what it asked bootloader to do. MBI now is a >> single chunk. Further than that there are only elf section tag and >> module tags which refer to external memory. I think it should be easily >> trackable now. > > Unfortunately a lot of OSs are written by C programmers who do the > absolute minimum to setup paging in a small piece of startup code > written in assembly, before jumping to their "main()". This means they > allocate RAM for page tables, etc before they've parsed or checked > anything; usually by searching the memory map for the first "usable" > area and using the first pages of that area. > > Unfortunately I'm often the person that needs to explain to them that > "usable" doesn't mean usable; and that their code only works by > accident (and their initialisation code could overwrite things needed > by the OS later if it's booted by a different multi-boot compliant > boot loader; including future versions of GRUB and not excluding > non-GRUB boot loaders); and that the only memory they can safely use > before determining what is usable and what isn't is the space in their > ".bss", which usually happens to be linked to a virtual address (e.g. > above 0xC00000000) and not the address it's actually loaded at.The > other alternative is for the initialisation code to copy everything > from the "usable" areas into their ".bss" so that they can assume that > "usable" means usable (but there's no maximum size for the multi-boot > information and no way to know how big "big enough" is, and this won't > work if there's any extra modules). > > Basically, regardless of how the OS handles the problem, the "small > piece of startup code written in assembly" ends up being an ugly mess. > > If multi-boot guaranteed that "usable" actually did mean usable then > the problem goes away. Alternatively you could rename it, so that > "type 1 = potentially usable maybe" so that beginners realise they're > screwed before they write their dodgy code... ;-)
This does sound like there ought to be different codes for "usable - unused" vs "usable - valid". I think the original objection may have been to enumerating all the different kinds of "usable - valid" regions which could snowball into a very large number of IDs. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
