|
From: Hans-Peter J. <hp...@ur...> - 2003-08-01 18:09:37
|
Dear Ken, On Friday 01 August 2003 11:35, Ken Yap wrote: > In 5.1 and above menus are devolved to a loadable image which uses > the redirection capability of Etherboot to specify which image to > load. I didn't feel that menus should be part of the core > functionality of Etherboot, mainly because of the issue of updating > ROMs, which is slower than updating disk images. Have a look at I'm 100% fine with this decision. > mkelf-nfl, which doesn't take the entries from the DHCP packet and > has no limitations on menu entries due to packet size. Yep, I've looked at it. In general, if I need to load some secondary menuing system, it does't matter, if this is 10L or 166K. But when I'm forced to use a pxe loader, etherboot >= 5.1 isn't an option anymore, since despite of the pxe target, it doesn't provide any surplus value anymore, no, better than that, it creates a nice useless boot loop. Options: use 5.0 with menus enabled, or go the grub way. The nice thing in grub from developers pov is the approach to provide some limited posix like f* functions to operate on files (one at a time), which seems to work fine with tftp, too. > While I have no philosophical objections to Etherboot code being used > in GRUB, and certainly no objections on licence grounds---it's GPL > after all---I do not want Etherboot to evolve towards becoming a disk > bootloader and certainly not splash screens and all that. We have > enough work as it is trying to keep up with ideas in network booting. > If however these capabilities can be provided by a general mechanism, > or Etherboot can be invoked as a subsystem to do network booting, > then I'll listen to the proposal. In short, like the kernel > developers, I like to push bells and whistles into user space; and I > prefer interoperability to feature bloat. That's definitely a good thing. Put the essential diskless boot stuff into the flashes, and daisy chain/delegate everything more complex to something else. BTW: Did you noticed the huge amount of (old) etherboot code in grub? This is one thing, I didn't like in this scenario: the repetition of device drivers in the different loaders. Much cooler would be to install and use an interrupt vector for basic nic device operations, such that chained boot loaders are able to use one set of device drivers. That would spare me the now necessary port of the current etherboot drivers to grub to not loose the track. I hope, you don't have any objections. Kind regards, Pete |
