RFC: New multiboot2 memory map entry type

[Seth Goldberg]

Hi,

The multiboot2 spec currently says the following regarding memory map entries 
(tag type 6 in the multiboot2 info tag stack):

             +-------------------+
     u64     | base_addr         |
     u64     | length            |
     u32     | type              |
     u32     | reserved          |
             +-------------------+

   `size' contains the size of current entry including this field
itself. It may be bigger than 24 bytes in future versions but is
guaranteed to be `base_addr' is the starting physical address. `length'
is the size of the memory region in bytes.  `type' is the variety of
address range represented, where a value of 1 indicates available RAM,
value of 3 indicates usable memory holding ACPI information, value of 4
indicates reserved memory which needs to be preserved on hibernation,
value of 5 indicates a memory which is occupied by defective RAM
modules and all other values currently indicated a reserved area.
`reserved' is set to `0' by bootloader and must be ignored by the OS
image.


 The proposal is to add an additional type (value = 6) that denotes runtime 
memory that some firmware marks as required to be mapped to take advantage of 
services after the end of boot (UEFI is the canonical example).  Without this 
information, it's impossible for a multiboot2-compliant OS to set up proper 
mappings for this memory.

 --S