Re: [Etherboot-developers] pxe

[<prl...@sy...>]

> It's unlikely that Etherboot will ever implement the full PXE API.  
> Implementing the TFTP and UDP layer calls would be relatively 
> straightforward, but implementing the UNDI API calls would require a 
> significant restructuring of the internal Etherboot driver API.  This 
> would offer *no* benefits other than being able to implement the full PXE 
> API, and would have significant downsides in that Etherboot drivers would 
> have to become a lot more complicated.  (For a start, they'd have to use 
> interrupts instead of polling.)

> PXE emulation, in the sense of implementing part of the PXE API, is 
> probably a better goal than a full PXE implementation.

You guys seem to use the word "emulate" in an odd way.

http://dictionary.reference.com/search?q=emulate

I agree with the logic of what you are saying, Michael, just noting that
"emulation" seems like the wrong word for "partial implementation".

A partial implementation would be fine, I'm sure: NBPs are likely use
the higher level APIs, as Eric pointed out in an earlier thread. Almost
anyone else will be using the "features" of PXE (unlike Etherboot with a
UNDI driver, which is trying to *replace* them).

Intel might take a dim view of using "PXE" for something incomplete,
though, even if it is effective.  How about PSKE? Or POXE? PIKI?

Thinking aloud, how feasible would it be to make a quasi interrupt
driven driver, on top of the (existing) polling drivers, which could be
exported as UNDI?  I can't help noting that this *would* be emulation as
I understand the term. :-) I do realise that this would be an extremely
pointless project if NBP actually needs it - it is not a practical
suggestion, but once the PXE skeleton is in place and stable I can
imagine that someone might try.