Xiu-Yan Wang writes:
> To implement what you want the underlying nic driver should support
> polling, which is not available yet.
> 
> Currently, the handling of of rx interrupts is usually multiplexed with
> that of other interrupt events in the interrupt handler under legacy
> interrupt mode, though the ISR focuses mainly on receiving.

Right, and I'm not sure that this is identically the sort of "polling"
that Crossbow has in mind (though I think you should check with that
project team to see if there are functional overlaps that would be
useful).

The sort of polling interfaces needed to make a decent panic-time dump
system are:

        - A function call to enter polling mode, which disables all
          interrupt sources.

        - A function call that checks whether a packet has been
          received, and returns a flag.

        - A function call that grabs one packet from the receive
          buffer, and returns it.

        - A function call that places a new packet into the transmit
          buffer (reclaiming any buffer that might have been there),
          or returns an error if transmit is busy.

This obviously runs with all interrupts disabled.  And there should be
no need at all for the high-level software to call the driver's
interrupt service routine.  Just disable the interrupts completely,
and have all the work done from the explicit packet I/O calls.  You
shouldn't even have to check any of the interrupt registers -- most
Ethernet hardware has all the status bits you need right in the ring
buffers.

-- 
James Carlson, Solaris Networking              <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to