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 dont 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 kernels 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 motherboards ROM and will run only on that motherboard, it is possible to do a thorough testing of how well the kernels IDE driver works with the motherboards 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 shouldnt 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