|
From: <ebi...@ln...> - 2002-12-12 18:08:23
|
Peter Lister <P.L...@sy...> writes: > Congratulations Matthew. > > > Great. If you like reading the PXE spec, maybe you can do Etherboot on top of > > PXE's UNDI without using an Etherboot's native network driver :). > > The Etherboot driver would in fact be written for PXE's *UDP* interface, > not UNDI. Eric B pointed out my loose terminology: no-one needs UNDI per > se unless genuinely implementing a new network protocol (not UDP/IP). We > want the PXE driver abstraction, but we don't have to use it directly. To be clear. I believe etherboot should use the PXE UNDI layer explicity, when writing an etherboot driver. Any other layer would cause us problems, (we could not send arp, or igmp packets for example). Plus using UNDI directly we have the most direct access to the underlying UNDI bugs. I actually have an ia64 UNDI driver at the moment. But ia64 UNDI != i386 UNDI, so the code cannot be simply reused. The case I was talking about earlier was for etherboot reexporting PXE services to bootloaders like syslinux. In which case all we need to do is export the PXE UDP layer. > > This, of course, is an option in addition to using the native driver. > > A generic image with multiple drivers could use PXE as a default: it is > fine for simple cases and new hardware; No. The reliable thing to do would be to use PXE as the fallback if there is not a native driver. That way in most cases you steer clear of PXE/UNDI bugs and only have to worry about etherboot bugs which are fixable. > anyone who finds it restrictive > (e.g. by having multiple NICs or wanting better multicast) can load the > native driver for the nic(s) via tftp. That way everyone is happy. :) I suggest you go have a long talk with Marvin if you think you can make everyone happy. Eric |
