[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