[LinuxBIOS] Userspace boot manager stored in ROM

[Vlad]

Hi,

I noticed that there is a proposed Google Summer of Code project
(http://linuxbios.org/GSoC) to fork IDE drivers from the Linux kernel
and port them to Linux-independent boot managers like GRUB2. I don’t
think this is a good design choice or a sustainable solution. There
are many different IDE controllers, each with its own peculiarities
that must be taken into account by the drivers. The volume on the
Linux-IDE mailing list (http://marc.info/?l=linux-ide) can reach more
than 1,000 messages a month, and critical fixes to the drivers are
made daily. Who is going to make sure that all these fixes are ported
to the boot manager on a regular basis?

I think a more sustainable solution is to write a userspace boot
manager that harnesses the kernel’s I/O facilities. LinuxBIOS, the
Linux kernel (payload) and the userspace boot manager would all be
stored in the ROM. The userspace boot manager would mount devices in a
pre-defined order (configurable by the user) and search for a file
named “grub.cfg” on that device. This file is used to specify the
pathname of the kernel(s) stored on the device, the parameters to pass
to the kernel(s), and the descriptions of various boot options. The
userspace boot manager would then display these options to the user
and let him/her choose (a timeout is normally specified in the
grub.cfg file, after which the default option is automatically
chosen). The userspace boot manager then kexecs the chosen operating
system from the device.

Here are the foreseen advantages and disadvantages of a userspace boot
manager:

Advantages:
     1)No need to port drivers for IDE, VGA, keyboard, and mouse from
the Linux kernel to the boot manager.
     2)Bug fixes to the drivers are automatically included in new
Linux kernel releases.
     3)Because the Linux kernel payload is flashed to the
motherboard’s ROM and will run only on that motherboard, it is
possible to do a thorough testing of how well the kernel’s IDE driver
works with the motherboard’s IDE controller. Contrast this to a
scenario where GRUB2 is distributed on installation CDs and must
recognize any IDE controller that is thrown at it.
     4)Many more types of devices become bootable by merely enabling
support for them when compiling the kernel. Examples include FireWire
disks, ZIP disks, USB flash keys, SD/MMC cards, network locations (via
ethernet, wireless, dialup modem, bluetooth) as well as the more
traditional media such as CD/DVDs, floppies, and hard drives.
     5)Bootable media can be encoded in any filesystem recognized by
Linux (FAT, ReiserFS, EXT2/3, NTFS, XFS, JFS, etc).
     6)The userspace boot manager would contain relatively little code
that mostly deals with presentation (ncurses or X.org-based). 
     7)The hardware interface that the Linux kernel exposes to
userspace apps is very stable, and HAL (http://hal.freedesktop.org)
can be used to make hardware discovery even simpler.

Disadvantages:
     1) Distributions would have to follow a well-defined standard for
formatting their grub.cfg file. But this shouldn’t be a problem
because grub.cfg comes from GRUB and should therefore already be the
standard. And even if the grub.cfg file is completely left out of the
installation media, the userspace boot manager could still be
configured to let the user type the pathname where the kernel is found
on the device (like FILO does it).

So, what do you guys think about a userspace boot manager stored in
the ROM?

Thanks,
Vlad

____________________________________________________________________________________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html

[ron minnich]

On 3/19/07, Vlad  wrote:
> So, what do you guys think about a userspace boot manager stored in
> the ROM?

I think it is inevitable. I think that the best boot loader is Linux.
We already showed how to do it on OLPC, but the size of the boot rom
(1 Mbyte) was too small. I think that 2 MBytes works however.

So that's my feeling. I am glad you asked this question, and I think
what you are saying is very sensible.

thanks

ron

[Stefan Reinauer]

Ha! Very good reasons, but I there's a downside to it, as well.

* Vlad  [070320 03:03]:
> Hi,
>
> I noticed that there is a proposed Google Summer of Code project
> (http://linuxbios.org/GSoC) to fork IDE drivers from the Linux kernel
> and port them to Linux-independent boot managers like GRUB2.

Huh? That would be a really stupid attempt, really. Where did you read
that?
> I don’t
> think this is a good design choice or a sustainable solution. There
> are many different IDE controllers, each with its own peculiarities
> that must be taken into account by the drivers. The volume on the
> Linux-IDE mailing list (http://marc.info/?l=linux-ide) can reach more
> than 1,000 messages a month, and critical fixes to the drivers are
> made daily. Who is going to make sure that all these fixes are ported
> to the boot manager on a regular basis?

For an IDE driver in the bootloader you don't need all that stuff. 
A complete IDE driver easily fits into 1000 lines of code, and we even
have had one in LinuxBIOS directly for many years now. It is not fast,
not Ultra DMA, and polling only. But all it ever does is load an OS from
disk. We never had to change it.

For SCSI drives, an int13 based implementation will be needed, similar
to what we do with VGA bioses now.
> I think a more sustainable solution is to write a userspace boot
> manager that harnesses the kernel’s I/O facilities. LinuxBIOS, the
> Linux kernel (payload) and the userspace boot manager would all be
> stored in the ROM.

The drivers in Linux are far too complex for such a simple thing as IDE
booting.

This also means two things:

* It makes LinuxBIOS unusable for systems where the user did not
  replace the flash part with a bigger one (ie. because he does not want
  to or because it is soldered on)

If you believe EFI will help us achieve this, tell me when you think
  EFI is coming ;-)

* You will have to recompile your BIOS every time you change the SCSI
  adapter.

Ok, I am trying to sneak away without noticing that a magic piece of
software is needed in both cases, whether you run on Linux or not.
>  1)No need to port drivers for IDE, VGA, keyboard, and mouse from
>
> the Linux kernel to the boot manager.

IDE, VGA and keyboard are very simple in the bios. Far more simple than
in Linux (and with a lot less requirements to the system)
>  2)Bug fixes to the drivers are automatically included in new
>
> Linux kernel releases.

As are regressions.
>  3)Because the Linux kernel payload is flashed to the
>
> motherboard’s ROM and will run only on that motherboard, it is
> possible to do a thorough testing of how well the kernel’s IDE driver
> works with the motherboard’s IDE controller. Contrast this to a
> scenario where GRUB2 is distributed on installation CDs and must
> recognize any IDE controller that is thrown at it.

No, wait. That is of no concern to the Grub2 on an install CD. The grub2
used in LinuxBIOS is directly put to flash. And the IDE driver uses any
IDE class device it finds and just reads from it. If you don't try to be
witty, IDE is 100% the same on all chipsets.
>  4)Many more types of devices become bootable by merely enabling
>
> support for them when compiling the kernel. Examples include FireWire
> disks, ZIP disks, USB flash keys, SD/MMC cards, network locations (via
> ethernet, wireless, dialup modem, bluetooth) as well as the more
> traditional media such as CD/DVDs, floppies, and hard drives.

Given that you recompile your bios daily or you have a 64+ Megabytes
flash chip. Both is not exactly on the horizon for a viable solution.
>  5)Bootable media can be encoded in any filesystem recognized by
>
> Linux (FAT, ReiserFS, EXT2/3, NTFS, XFS, JFS, etc).

No problem, we can do that since years with grub or FILO.
>  6)The userspace boot manager would contain relatively little code
>
> that mostly deals with presentation (ncurses or X.org-based).

Kexec is not exactly simpler than other bootloaders. The fact that it
already bloats the kernel per default does not make it easier or less
error-prone, does it?
>  7)The hardware interface that the Linux kernel exposes to
>
> userspace apps is very stable, and HAL (http://hal.freedesktop.org)
> can be used to make hardware discovery even simpler.

Stable driver API in Linux? That is a tough claim ;-)

With how much flash will you run hal?
> So, what do you guys think about a userspace boot manager stored in
> the ROM?

It does not solve the problems if you want to go into width, IMO. If
you're building a single cluster or similarly homogeneous , it is sure
perfect.

I know a lot of people love it. The stuff you can do with it is great.
There's projects like kboot.sf.net that could be enhanced to do what you 
described. Any takers for GSoC are highly welcome.

[Stefan Reinauer]

* Vlad  [070320 03:03]:
> I think a more sustainable solution is to write a userspace boot
> manager that harnesses the kernel’s I/O facilities. LinuxBIOS, the
> Linux kernel (payload) and the userspace boot manager would all be
> stored in the ROM.

It is there as another GSoC project, even though I hoped Ron or anyone
else could add to it:

http://www.linuxbios.org/GSoC#Improve_Linux_as_a_BIOS