[haiku-development] Re: EFI (was: multi-selection semantics)
- From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 09 Jun 2007 13:15:52 +0200
DISCLAIMER: Please take all of the following with a grain of salt, as I'm
afraid I do not *really* know what I'm talking about ;o)
On 2007-06-09 at 00:27:32 [+0200], Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
wrote:
>
> On 2007-06-08 at 18:24:36 [+0200], Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> > On 2007-06-08 at 11:51:15 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
> > wrote:
> > > For that to work we would need a working solution first. Then, we would
> > > need to define a protocol on how the kernel knows what service to use -
> > > and how.
> > > Also, the boot loader should then be smart enough to load the
> > > networking stack, and eventually all networking drivers before starting
> > > the kernel.
> >
> > Hm, wouldn't the bootloader have to *include* the networking stack and the
> > drivers? Maybe I'm wrong, but there would be no way to access the modules,
> > since they are living on the other side of the network link, right?
>
> ATM, the boot loader contains a mini networking stack. It implements my
> simple remote disk protocol (and could implement NBD), thus having access to
> the complete boot volume. And it does (or should) indeed load all required
> modules from there.
Ah, I suppose what I do not dig is the "monolithic" architecture of the second
stage bootloader. If I understand the current idea correctly, *if* haiku would
ever want to support booting from a USB disk, the bootloader would have to
provide a USB-stack, right? That USB-stack (as the current mini network stack)
is separate from the one in the kernel, since it executes in a different
environment (at least without most kernel services).
I personally would find it cleaner if the second stage bootloader would only do
this:
- load the kernel
- load an initial fs (served in ram)
- jump into the kernel
This way, the initialramfs would be able to use the standard kernel modules for
networking, USB and whatever else might be needed in some specific boot
environment.
> > AFAIK, PXE offers downloading an initramfs (cpio-fs), too, so we could stuff
> > the needed stuff in there and then the bootloader could tell the kernel that
> > there is such a beast.
> > The kernel would then of course have to unpack/mount the initramfs and
> > invoke
> > a specific program, which in this case (NBD-boot) would set up networking,
> > mount /boot and then would let the kernel continue the booting process.
> >
> > Marcus: When I tested it last time, I think I noticed that your PXE
> > bootloader does not use any initramfs yet, is that correct?
> >
> > Is there any reason not to use an initramfs?
>
> I'm not sure if that would actually simplify things. It also doesn't sound as
> flexible, for someone has to build this initramfs and put the right things
> into it.
I agree that having an initramfs isn't simpler, but I would say that it is a
bit more flexible than a monolithic bootloader:
1. There'd be no need to reimplement every required service inside the
bootloader, but the standard modules could be used. This will make it easier
to support new boot "platforms" (USB, RAID)
2. The user (gasp!) could influence the booting process much more easily, should
that ever be necessary (as we'd have to provide tools to change the initramfs
anyway).
On the other hand, we would have to solve (at least) two problems:
1. The tools for creating the initamfs would have to be implemented and
integrated into the build process.
2. The bootloader would have to know how to access the initramfs (that's solved
for PXE, but not generally for the standard disk-based type of boot).
Anyway, just my thoughts, really. I'm sure someone will point out what I'm
missing...
cheers,
Oliver
Other related posts:
