On 12/28/05, tlaronde@polynum.com <tlaronde@polynum.com> wrote:
> 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.

Yes... while doing this patch, I've already found the lack of some
features in MB.  For example: no real way to get the kernel's
file name (because the cmdline field is grub-specific) and no way
to tell where the physical console is).

Nevertheless, I've mailed the grub developers.  Maybe they could
extend the MB spec in time for grub 2, making it useful :)

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

Just look at grub 2.  IMVHO, they are going a bit too far...

But anyway, having MB, you could theorically write a little boot loader
that could boot multiple different OSes transparently.  (No need for all
the "bloat" in grub.)

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

Of course it's not a problem.  But it's tricky.

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

Sure, but frankly, I'm doing this to learn something about the
NetBSD boot process.  And in fact I've learnt quite a lot already :)
(I'd say enough to write a rather complete manual page.)

Cheers,

--
Julio M. Merino Vidal <jmmv84@gmail.com>
The Julipedia - http://julipedia.blogspot.com/
The NetBSD Project - http://www.NetBSD.org/