Re: multiboot2

[phcoder <phcoder@gmail.com>]

These issues still remain
phcoder wrote:
> Hello I was looking into multiboot2 specifications and have some 
> suggestions:
> 1) double the size of flags. 8 features per category seems to be few. it 
> could even be made completely expandable by the following format:
> <magic>
> <number of flag dwords>
> <dword1 as defined in current draft>
> <dword2 as defined in current draft, next packet of flags>
> ...
> <checksum>
> 2) "All undefined flags *should* be set to zero for future use. "
> IMO in this place all OSes should be required to follow this rule in 
> current terminology it would be "must"
> 3) "The physical address to which the boot loader should jump in order 
> to start running the operating system."
> In current terminology should make no real sense here
> 4) "This tag should contain a string that enables operating systems to 
> distinguish between different bootloaders and different versions of the 
> same bootloader."
> Parsing strings may be difficult. Perhaps we could include a version tag 
> with a format dependent on bootloader and optionally a requirement that 
> higher numbers are newer versions?
> 5)memory map: "The order of memory maps is not guaranteed but a boot 
> loader should sort the items based on the starting addresses. "
> I don't like the optionality of this rule if it's included in 
> specifications it should be either required or dropped altogether. 
> Otherwise we risk to have OSes which rely on sorting and bootloaders 
> which doesn't sort. I'm personally for making it mandatory for reasons 
> similar to next entry
> 6) memory map. "<!> Tags of this type should be omitted on architectures 
> where the OS is able to retrieve this information from firmware. (Doing 
> do will encourage OS portability across bootloaders, and simplify GRUB 
> development and maintenance.) "
> This contradicts the goal of easier OS developement and may result in 
> semi-compatible OS and bootloaders. Additionally I think that 
> eliminating the necessity of use of firmware from OS is a good thing and 
> allows easier porting between architectures differing only by firmware
> 7) Command line tag. I propose to reserve the identifier 0x0005 for 
> command line and make it the same format as "Boot Loader Name" but 
> arguments shouldn't include kernel image name. This way we would prevent 
> OSes from trying to access this file by bootloader-specific name. In 
> addition in both "Boot Loader Name" and "Command-line" we should specify 
> the encoding to be utf-8
> 
> 


-- 

Regards
Vladimir 'phcoder' Serbinenko