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
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
