Re: [Etherboot-developers] pxe

[Michael B. <mb...@fe...>]

On Thu, 22 May 2003 prl...@sy... wrote:
> 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.

Two main obstacles that I can see:

1. The hardware interrupts need to be enabled.  This requires all the 
   drivers to be modified.

2. poll() needs to be capable of being called as part of an interrupt 
   service routine.

We don't actually need to implement ISRs, 8259A-handling code etc.; under 
the UNDI model the responsibilities are divided as follows:

UNDI driver: enable the interrupt on the NIC, pass back the IRQ number to 
the protocol driver ("protocol driver" in PXE terminology meaning the 
program that is using the UNDI driver).

Protocol driver: install an ISR for the specified IRQ and enable it.

Protocol driver: handle interrupts.  Call the UNDI driver's "ISR"  
routine to determine whether or not this interrupt has originated from our
NIC.  If so, set a flag and exit the interrupt handler.

Protocol driver: notice the flag set by the interrupt handler, call the 
UNDI driver's "ISR" routine again to read out the actual data.


In practice, we might be able to get away with the following modifications 
to all drivers:

1. In probe(): enable interrupts on the NIC, pass back the IRQ (probably
   via an extra member in the "dev" structure).

2. Split poll() into two routines:

a) poll(); a routine that *very quickly* determines whether or not there 
   is a packet waiting and does nothing else.  Must be able to be called 
   as part of an interrupt service routine.

b) receive(): receive the actual data.


This wouldn't allow us to implement the full UNDI API (with calls like 
"set MAC address", "get link speed" etc.), but it would be enough to cover 
all the calls that are essential for initialisation and transmitting / 
receiving data.  We could always hack round the other ones (e.g. return 
success for "set MAC address" as long as it's being set to it's current 
value anyway).

It's starting to look easier each time I think about it.

One interesting case would be PXEAPI on top of Etherboot on top of UNDI.  
This would involve having two !PXE structures in memory, which could 
really confuse a NBP.  I imagine we'd have to corrupt the UNDI driver's 
!PXE structure so that it still functioned but wouldn't be detected.

Michael