Re: multiboot2

[Yoshinori K. Okuji]

On Monday 06 April 2009 08:34:23 phcoder wrote:
> 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.

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.

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

This (i.e. a variable Multiboot header) has been raised several times on this 
list, and my conclusion is that it is not desirable.

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

I agree.

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

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

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

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

From another viewpoint, a boot loader can declare a part of memory for its own 
use, even after transferring control to an operating system, by specifying a 
memory map explicitly. So it can be useful to provide a memory map, even on 
an architecture which offers support for retrieving a memory map easily.

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

BTW, I agree that the command line should not include a filename.

Regards,
Okuji