Re: [Etherboot-developers] PXELOADER_KEEP_UNDI

[Peter L. <P.L...@sy...>]

>   I am trying to write up a generic 'nic' driver that make use of the
> PXE UNDI API, do I need to define PXELOADER_KEEP_UNDI? 

Hooray! Joe, I will personally buy you a beer when this first works!

I take it that you have a copy of the 2.1 pxespec doc [*]? 

The PXE API consists of 4 sections (pre-boot, UNDI, UDP, TFTP), which
can be unloaded if not required. Actually the current PXE "loader" does
not actually load anything - the nic's PXE firmware actually loads and
initiates it. It is really an *unloader* - once it finds itself running,
it unloads the PXE API sections - and then runs the same Etherboot code
(including the NIC driver) as if it had been loaded from ROM, floppy or
whatever. The PXELOADER_KEEP_UNDI has the effect of not unloading UNDI -
so yes, you'll need to keep that code (there isn't a lot of it) for a
UNDI driver to work. Vasil, who wrote the PXE (un)loader code, put in
the flag as a hint to the brave soul who takes on a UNDI driver.

A bit of history - the code was written last year when we needed to do
booting of cluster machines. I had some success in using EB from lilo
and ROM (we used 3c905Cs which are easily flashable), but we started
getting machines with unflashable PXE nic roms. It was also deemed
desirable at the time to say to a customer that we "supported" PXE. To
get Linux from PXE, the alternatives I could see were pxelinux or
bpbatch, but I wanted EB, so I tried naively to get PXE to load a DOS
environment and then EB via a COM file. I spoke to Vasil about this, and
he realised that it would be quite easy to get PXE to use EB as the NBP
(unlike me, he can code x86 assembler). A few days later he code
working; my only contribution was to help merge it with EB source tree
and give out some hints on using it. Marty Connor then did a detailed
description which has become PXE howto for Etherboot and LTSP.

This got round *our* PXE problem, and it seems that quite a few people
have used EB-via-PXE (Marty, do you know what the rom-o-matic download
stats are for the various forms of EB?). However, the main disadvantage
has always been that for simple cases where using the UNDI driver would
be desirable, one must select the right EB driver and build or get an
image from rom-o-matic. A UNDI driver would make EB-via-PXE into a
single, portable blob of code - a more viable alternative to pxelinux.
[To the pxelinux fans out there - I have nothing against pxelinux as
such, other than the fact of its reliance on PXE].

Notes...

Using the other PXE APIs (UDP, TFTP) seems like a really bad idea - the
commercial implementations have a reputation for poor quality. I know
you weren't suggesting this, but I'll mention it anyway. Stick to just
the driver.

Although an UNDI driver would be more convenient for thin clients and
e.g. LTSP, the choice of using an EB driver is still needed. Obviously
the UNDI driver only exists during a PXE boot, but using EB-via-PXE does
NOT mean that only UNDI should be used once a UNDI driver exists. PXE
implementations don't handle multiple NICs, so for >1 nic the EB drivers
are required.

And finally, though a UNDI driver is the obvious next step, the world
*also* needs PXE-via-EB, as well as EB-via-PXE, i.e. a PXE API based on
the existing EB driver code which allows existing PXE NBPs to run. So,
Joe, if you're looking for *another* project after the UNDI driver, how
about porting NILO (which currently uses OSkit) as an Etherboot module?
:)

[*] http://www.intel.com/labs/manage/wfm/wfmspecs.htm