Peter Lister prl@peterlister.co.uk writes:
On Wed, 2004-02-04 at 14:31, Stefan Reinauer wrote:
OpenBIOS is currently only reusing filesystem drivers from grub, but an interface for network booting so that etherboot drivers can be used should not overtop the fs efforts a lot.
Digressing slightly, please note that Etherboot is more than just the drivers - there is a significant amount of network code (now even TCP if one wants it), and it would benefit us all to share as much as possible; there is, for instance, an NFS client already.
Regardless the etherboot driver model and the open firmware driver model are essentially the same. (Independently derived though). The big difference is I believe OF drivers can have multiple cards working at once.
For some reason best known to themselves, the GRUB developers decided to use only Etherboot's drivers and brew their own network code. The result is that GRUB netboot is now lagging noticeably behind Etherboot in functionality, drivers etc - GRUB people now discuss "porting" Etherboot drivers, which is disappointing (have a look at the GRUB support forum and FAQ to see how little help there is on the network code compared to disk and fs). It would have made far more sense to co-operate on an open firmware network API, but hey ho... I'd like to see this happening fairly soon, so that any driver created for Etherboot immediately works with GRUB. So I encourage OpenBIOS to peacefully co-exist with GRUB and Etherboot rather than fork which is not a good way to encourage driver writers.
After seeing the GRUB code the amazing part is that it works. The problem is totally GRUB, the etherboot core is much more powerful. Some pieces of GRUB at the periphery are OK, like the FS drivers but the rest is not even worth thinking about. There is a reason GRUB has never been ported to run under LinuxBIOS.
BTW, there is work now on implementing PXE on top of Etherboot - pxelinux has already been demonstrated on top of Etherboot. This may force the issue somewhat, since even if PXE isn't the API one wants, it will at least help focus people into deciding what APIs they *do* want.
I've already implemented the API I do want. Open source and no callbacks.
Eric