Hello,

On Wed, Dec 28, 2005 at 05:25:34PM +0100, Julio M. Merino Vidal wrote:
> [..]
> 
> The GRUB [1] developers came up with the idea of designing a
> "standard" protocol between boot loaders and OS kernels, known
> as the Multiboot Specification [2] (I'll use MB for simplicity).  The
> idea behind this protocol is to enable any MB-compliant boot loader
> to execute a MB-compliant kernel without knowing any of its
> internal details.  (This way, you'd install your boot loader of choice
> and have it load any OS without "dirty tricks".)
> 

Just a note about the GRUB and the MB.
Actually, I made some work for GRUB some years ago, indeed fixing the
El Torito booting problem and trying to rework the directories hierarchy
to try to separate MI code from MD one (this was not accepted at that
time by the main GRUB developer).

After some thoughts, while the idea (of MB) seems interesting, IMHO it
is not, actually, that important.
The pleasant features of GRUB, inherited from the BSD bootloaders, are
the ability to do some basic searching/fixing/options at boot time. But
to be really interesting and powerful, some supplementary features are
necessary. While you start thinking about this, you see that you are
aiming to a bootloader that is indeed a minimal kernel on its own right
(and using the Linux kernel as a bootloader is one of the proposal---for
Linux---of the lilo's author IIRC).

So allowing to run tests on scratch of the NetBSD kernel, or allowing to
"reboot/reload" from the NetBSD kernel, or having a basic interpreter
in the kernel to explore the hardware seems to me more promising (the
Forth interpreter in the FreeBSD bootloader, if I'm not mistaken, is
something like that).

Altogether, this is not a real problem to chainload a "proprietary"
second stage bootloader from the mbr (for i386).

This is not to undervalue your work and, as a user---since I'm nothing
more to NetBSD---, I don't see a problem with a supplementary
compilation time option. Just to say that in the boot load area, there
are probably more potential in other directions.

Just my 2 cents.

Regards,
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C