[haiku-development] Re: EFI (was: multi-selection semantics)
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 09 Jun 2007 14:37:23 +0200
On 2007-06-09 at 13:15:52 [+0200], Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> 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)
Same here. :-)
> 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).
Not quite. If the boot platform (BIOS, Open Firmware, EFI) presents the USB
disk as it would present any other disk (I believe the BIOS does just that,
and OF is saner anyway), then our boot loader already supports booting from
those disks.
> 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.
[...]
> > > 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)
In fact the boot loader "only" needs to implement the services that the boot
platform itself doesn't support. Since in most cases some support needs to be
provided anyway -- e.g. you can't boot from a USB disk, if your BIOS doesn't
support that -- it's usually not that much that needs to be implemented.
In case of networking you're right, though, since the boot loader would
probably need to implement all the "high level" protocols we want to support.
> 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).
BTW, we already have a method similar to initramfs, which is used on a boot
floppy (or CD). The kernel and required modules live in a tgz archive that
the boot loader reads straight from a fixed position on the disk. I guess it
wouldn't be all that hard to support retrieving that archive from another
channel (e.g. TFTP).
I wouldn't use the initramfs method by default (i.e. for booting from
standard disks), but for network boot, it might indeed be the best choice.
CU, Ingo
Other related posts: