[I wrote this message several months ago and sent it to Erich
Boleyn. I didn't receive any reply. Now that I've just noticed the GNU
GRUB project, I'm sending it to this list in the hope that it will be
useful. Comments about GRUB itself refer to GRUB-0.5 as released by
Erich Boleyn; perhaps some of the bugs have alerady been fixed.]
[I note that there's no link to the Multiboot standard from the GNU
GRUB web page. Perhaps this would be a good idea.]
(GRUB version 0.5, Multiboot standard version 0.6)
I've been implementing a netboot loader for Multiboot kernels
recently, so I've been looking closely at the Multiboot Standard
document and GRUB. I've found some minor problems with both.
The problems that I have with the standard are mainly that it is
imprecise, and poorly worded in places. Parts of the document seem to
be requirements for a possible standard ('should provide', etc.) and
are obviously left-over from the early design stages. There seems to
be a general confusion over a.out and ELF, part of the standard
talking about a.out symbol tables and 'ELF support will be added
later', and other parts assuming ELF.
Here are my comments, section-by-section. Some of them are quite
petty, to do with wording and grammar, but the rest are more
substantial. The important ones are flagged with 'XXX':
* Motivation
A little colloquial - 'screwed' in a standards document?!
* Terminology
Use the term "boot modules" to be consistent with the rest of the
document.
* Scope and Requirements
** Architectures
The plural of PC is PCs, not PC's. ("Greengrocer's apostrophe"
problem: you see it on signs advertising "apple's" and "pear's".)
The plural of OS is OSs or OSes, not OS's.
** Boot-time configuration
You're talking about what the standard should say. Don't. Talk about
what it says instead.
** Convenience to the OS
First paragraph, "...boot process is created" should read "...boot
process is completed"
Third paragraph: choose between Multiboot and MultiBoot and use is
consistently through the whole document.
XXX Third paragraph: all Multiboot kernels must contain at least the
required part of the Multiboot header. Multiboot kernels which are not
ELF must set bit 16 of the flags and include the address fields. This
isn't made clear.
** Boot modules
Second paragraph: "provides" rather than "should provide".
* Details
The standard specifies; it's already been written!
** OS Image Format
XXX First paragraph: lose the sentence about only supporting a.out;
it's out of date.
XXX First paragraph: it's probably a good idea to constrain where a
kernel image can be loaded; most boot loaders will be unhappy with
images below 0x100000, for example. Specifying 0x100000 as the minimum
link address would be good.
XXX Second paragraph: we don't do a.out!
XXX Diagram: the offsets for the optional fields are out by 4;
header_addr should be offset 12, load_addr offset 16, etc.
Descriptions of bits: it's a good idea to give them names.
XXX Bit 16: the offsets are wrong.
XXX Bit 16: the specification should be more emphatic about what the
bootloader does if this bit is set; it _MUST_ use the fields in the
Multiboot header, rather than the executable header. Also, the bit
_MUST_ be set if the image is in any format other than ELF.
XXX Bit 16: GRUB gets this wrong; if the image is ELF then it ignores
bit 16.
** Machine state
XXX This section isn't precise enough. It should include more
information on the memory available to the operating system
immediately after boot. At the moment, the operating system can't use
any memory outside its data and bss sections, because the Multiboot
information could be anywhere else in memory. This is bad, because the
Multiboot information can be arbitrarily large (lots and lots of
modules, for example) and the kernel needs to move this information to
its internal data structures before it can carry on. The kernel stack
can only go in the bss as well, which is possibly wasteful later on.
XXX I suggest that you specify that the Multiboot information will
always be below 640K, and that boot modules will always be loaded
immediately after the kernel image. The kernel can then do a simple
scan of the modules list to find out the lowest available address, and
a scan of the memory list to find out how much contiguous memory is
available there. This can be done in O(1) space, and the kernel can
then start dynamic memory allocation in the area it's discovered.
** Boot Information Format
XXX Paragraph two: I think this is a bad idea; see comments on
previous section.
Descriptions of bits: give the bits names!
XXX Bit 1: what does this field describe? Where the bootloader was
loaded from? Where the kernel was loaded from? Where some of the
modules were loaded from? I think it's obvious it's supposed to be
where the kernel was loaded from.
XXX Bit 1: GRUB gets this wrong. GRUB-0.5 loaded from floppy, loading
a Multiboot kernel from (hd0,2)/boot/mbtest sets the field to
0x00020000, which is obviously bogus. GRUB loaded from the boot sector
of (hd0,2) gets it right, and sets the field to 0x8002ffff.
Bit 2: "the the command line" -> "the command line"
Bit 3: call them "mods_*" fields for consistency with bit 0.
XXX Bits 4 and 5: does any bootloader currently use these? Bit 4 is
talking about a.out symbol tables; we don't do a.out. Bit 5 could be
useful.
XXX Bit 6: this description is very confusing; I had to look at the
GRUB source code to work out what it is talking about. List the
offsets in the diagram as 0, 4, 8, etc. and specify that the 'size'
field gives the size of the rest of the structure, i.e. the total
length is size+4. Specify that mmap_addr points at the 'size' field of
the first structure, not at the 'BaseAddrLow' field.
Note that a more complete description of the eax=0xe820, int 0x15 BIOS
call is given in the ACPI specification; it defines memory region
types 3 and 4 as well.
XXX I suggest that the standard be extended to be able to return more
information gained from the BIOS; hard disk drive geometries, MCA bus
feature table, APM BIOS information, whether a PS/2 mouse is present,
etc. - basically everying Linux works out in its setup.S. There's no
point requiring Multiboot kernels to return to real mode during
initialisation to pick this information up.
* Notes on PCs
Don't include hyperlinks; include the information inline. It's more
useful when printed out that way.
----- (end of comments)
I'm prepared to write a draft version 0.7 of the standard and send it
to you for comments; my printed paper copy has more scribbled comments
on it that I didn't think worth mentioning in this message.
I've written a very simple program that can be used to test Multiboot
bootloaders; it's available at http://www.cl.cam.ac.uk/~sde1000/
The network bootloader I mentioned at the start of this message is
'Netboot'; see //http://www.han.de/~gero/netboot/
I've written a netboot image generator called 'mknbi-multiboot' that
turns Multiboot kernels and associated modules into images that can be
loaded by Netboot. It works well enough to start gnumach, and passes
all the tests that I can think of. I haven't released it yet; I don't
think it's portable enough (all the other mknbi programs will run on a
wide variety of machines; I suspect mknbi-multiboot will currently
only work on 32-bit little-endian machines).
Steve Early
