Ha! Very good reasons, but I there's a downside to it, as well.
* Vlad vladc6@yahoo.com [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 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 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 fromthe 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 newLinux kernel releases.
As are regressions.
3)Because the Linux kernel payload is flashed to themotherboards 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 enablingsupport 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 byLinux (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 codethat 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 touserspace 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.