Matt Thomas wrote:

> 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?

One thread might be hanging in a USB bus transaction when the watchdog call comes.
Then there is no thread vailable to reset the adapter.  This could probably be worked
around, though.


> Simply the logic would be a loop doing: (handle any ioctl, transmit a single packet,
> receive a packet).

There are the following in events (as far as I can see):
 * call to start (for starting transmission)
 * transmit completion interrupt
 * receieve completion interrupt
 * adapter status change interrupt
 * watchdog call
 * ioctl
The last of these is always (I assume) from a process context, so it doesn't have to
happen in the thread.  The other are performed from an interrupt context and would
have to send a message to the thread to get the service executed.
A problem is that servicing on of these calls can take a long time (several ms since
it needs several bus transactions), and during that time the thread will no be able to
respond to other service requests.


--

        -- Lennart