|
From: <ebi...@ln...> - 2003-08-03 17:49:30
|
Hans-Peter Jansen <hp...@ur...> writes: > 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. I have no problem at all using 5.1 with pxe. All it takes is a single if statement in the dhcpv3 configuration file to distinguish between etherboot and pxe. > 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. I am amazed you are looking at the grub code and not going blind... I guess if you are not digging into it too deeply the code looks o.k. > > 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? The old etherboot drivers in grub are known about. > 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. Chained drivers are so wrong. The reason they are wrong is very simple, software on a ROM is never updated. As long as the software on the ROM is good enough to do it's one thing that is all that is required of it. As for porting please notice that the 5.2 drivers are much easier to host. Now if you want something really fun that saves all of the work of replicating drivers. I can hook you up with a kernel with kexec support and you can use all of it's drivers and boot anything you want. Eric |
