[LinuxBIOS] Userspace boot manager stored in ROM
stepan at coresystems.de
Tue Mar 20 08:58:40 CET 2007
Ha! Very good reasons, but I there's a downside to it, as well.
* Vlad <vladc6 at yahoo.com> [070320 03:03]:
> 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
> 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?
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 kernels 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
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
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
> 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.
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
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.
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de • http://www.coresystems.de/
More information about the coreboot