On Sun, 12 Sep 1999, OKUJI Yoshinori wrote:
> From: Stephen Early <[EMAIL PROTECTED]>
> > The problems that I have with the standard are mainly that it is
> > imprecise, and poorly worded in places.
>
> If you send patches for them, that would be much better.
I can do that. Where is the canonical text of the Multiboot standard
at the moment? I was working from the HTML in GRUB-0.5; I see that
there's a .texi version as well now (with identical text).
Since multiple implementations of Multiboot-compatible bootloaders
exist it would probably be a good idea for the Multiboot standard to
have at least its own web page, so that authors of other bootloaders
don't necessarily have to refer to the GRUB package. [Specification
and implementation should be separate where possible.]
> > XXX Bit 16: GRUB gets this wrong; if the image is ELF then it ignores
> > bit 16.
>
> I'm afraid that this bug still remains in the current, but I'm not
> planning to fix it in the near future, because I don't think any real
> problem occurs due to it.
Consider this situation: we have a kernel that is intended to run at
virtual address 0xc0000000. We link it for that address, and include a
small amount of hand-written code at the start of the image to set up
page tables, enable paging and jump at the real start of the code. As
far as the ELF headers are concerned the load address for the program
text is 0xc0000000, which will upset GRUB. The Multiboot information
structure can have bit 16 of the flags set, and contain appropriate
load address and entry point information.
> > 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.
>
> Maybe that would be better, but I'm not sure. Anyway, the OSKit
> already provides a convenient library to support the Multiboot
> information, so it may be better that we leave it unchanged.
Not everybody writes operating systems using the OSKit. They should
not be expected to do so.
The startup sequence of a Multiboot-compatible kernel built using the
OSKit is fairly complex - it involves copying the Multiboot
information structure into the BSS, and initialising a physical memory
allocator such that areas containing boot information (the command
line, module info structures, boot modules themselves, etc.) are not
touched.
I believe this complexity is needless - by constraining where the
bootloader can put boot information we can make operating system
support for the Multiboot standard much easier. Hopefully this would
encourage wider use of the standard. Current Multiboot bootloaders
leave the boot information below 640Kb anyway, so specifying this
constraint would not cause any compatibility problems.
On another matter: I believe it would be useful to extend the range of
information that can be reported in the Multiboot information
structure. Reporting at least as much as the Linux kernel setup.S code
would be helpful: hard disk parameters, presence of PS/2 mouse, APM
BIOS information, video mode information. This would prevent the
Multiboot kernel from having to return to real mode to retrieve this
information.
I think it should be made clear that the mmap information is exactly
the output of the int 0x15, eax=0xe820 BIOS call. This enables
operating system developers to assume that the information hasn't been
tampered with in any way (removing regions with types that the
bootloader doesn't understand, for example: this would prevent
ACPI-aware kernels from functioning properly).
> > The network bootloader I mentioned at the start of this message is
> > 'Netboot'; see //http://www.han.de/~gero/netboot/
>
> I have an unrelated question: What is the relationship between
> Netboot and other network bootloader, such as NILO? I'm wondering why
> there are two distinct projects for the same goal, though both are
> GPLed.
I don't know. I looked at the available network bootloaders (at the
time it was a choice between Netboot and Etherboot), decided that
Netboot fit my requirements better (a wider range of drivers
available, given that DOS drivers supplied with cards can be
incorporated in Netboot bootroms), and added Multiboot support to it.
Steve Early
