Re: multiboot2

[phcoder <phcoder@gmail.com>]

Yoshinori K. Okuji wrote:
>>> 1) double the size of flags. 8 features per category seems to be few.
> 
> I do not agree on this. As you can see, most bits are still undefined after 
> over 10-year usage of the Multiboot Specification. I do not want to change it 
> without any real issue.
> 
The difference is that multiboot2 is meant to be portable
>>> 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
> 
> This is not an italic "should". Just a natural use of English wording.
Ok
> 
>>> 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?
> 
> I do not think so. The purpose of this tag is for human reading only. For 
> example, you might want to examine what boot loader booted up your operating 
> system. So, as long as it is readable for human, that's okay. IMO, operating 
> systems must not change behaviors based on this tag.
> 
Ok
>>> 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
> 
> There's a good reason to make it optional. If you see GRUB only, you will 
> think that this behavior should be always implemented, but some boot loaders 
> are more nervous about the code size, so they want to skip as many features 
> as they can. In fact, AFAIK, Etherboot didn't implement sorting in its 
> Multiboot support.
> 
What I want is to avoid is the bitrot as with multiboot1 when due to 
different issues some kernels boot only with some booters. Such a 
situation defeats the purpose of the standard
>>> 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
> 
> It is hard for me to say which is better.
> 
> In reality, every OS needs to interact with underlying firmware more or less 
> to be functional (power control, interrupt handling, etc.). So giving a 
> memory map does not eliminate the necessity of interactions with firmware 
> anyway.
> 
This isn't entirely true. Most of OS use their own firmware-independent 
drivers for most devices. If it doesn't recognize the firmware perhaps 
some functionality will be disabled but at least OS will be able to boot.
This isn't the case with a lot of current OSes specifically targetting 
one or another firmware but I hope it will vhange in the future because 
of advent of alternative firmwares.
Furthermore different firmwares may implement the same interfaces. A 
major example is EFI, coreboot and BIOS implementing ACPI. If we add a 
tag pointing to RSDP then the kernel won't need to know whether it's on 
EFI, BIOS or coreboot.
>>> 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
> 
> Seemingly, someone made a bad change on the draft, so the information is lost:
> 
> http://grub.enbug.org/MultibootDraft?action=diff&rev2=23&rev1=22
> 
> Hollis's idea was to use the same format as for modules to give information 
> about an OS image. A part of this change must be reverted. It is wrong to 
> adopt the spec to the implementation.
> 
It's ok with me. Quick look through the code suggests that probably 
kernel tag is created with type MODULE and that it also has an 
additional field type. I will check it tomorrow but it looks like a bug 
somewhere
And what about encoding?
> BTW, I agree that the command line should not include a filename.

> 
> Regards,
> Okuji
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel


-- 

Regards
Vladimir 'phcoder' Serbinenko