Re: Multiboot2 Suggestions

[address@hidden]

>>> 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.