Subject: Re: Advice about network driver needed
To: Lennart Augustsson <firstname.lastname@example.org>
From: Matt Thomas <email@example.com>
Date: 12/25/1999 23:32:51
At 04:20 PM 12/25/99 , Lennart Augustsson wrote:
>I'm looking at a driver for a USB Ethernet adapter (with the ADMtek Pegasus chip).
>In principle the chip looks quite straightforward to handle, but there is a big snag.
>It seems that in network drivers most of the processing happens in interrupt routines;
>a receiver interrupt to deliver a packet up, a transmitter interrupt to send the next one,
>the watchdog routine to reset the chip etc.
>All these routines need to access registers in the chip, and here comes the problem. You
>cannot easily access the registers. An access to a chip register requires a USB bus
>transaction, but these take a long time and need to use tsleep() (which is banned in
>So there are several ways to handle this:
> * Use delay() instead of tsleep(). This is totally unacceptable, since it would make the
> driver busy-wait for about 1 ms. (FYI, the FreeBSD driver does this.)
> * Use a state machine (which can be coded in many ways). This means that a register access
> will now be a two step operation: start the access and call a completion routine to
> do the rest of the job. This is quite tedious.. :(
> * Use a kernel thread for driver. The interrupt routine would then just wake up the
> kernel thread and have it complete the operation. The problem with this is that
> I think you need at least two threads for the driver to avoid deadlock. This seems
> excessive. :(
In this instance I'd use a kernel thread for the majority of the stuff but think about making
the frequently done stuff via a state machine to avoid context switches. Since USB Ethernet
can't be full duplex (right?), why would you need more than one thread per device?
Simply the logic would be a loop doing: (handle any ioctl, transmit a single packet,
receive a packet).
Matt Thomas Internet: firstname.lastname@example.org
3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt/
Cupertino, CA Disclaimer: I avow all knowledge of this message