Brook Milligan <brook@biology.nmsu.edu> writes:

> I am writing a device driver for the first time and have a few
> design-type questions.  The device in question communicates with the
> host in two ways.
...
> This seems rather straightforward but, especially since I am new to
> device driver design and interrupt handling and kernel programming, I
> am open to comments on whether this is a reasonable design and on how
> to improve it.

The first thing that comes to mind is that the flag/idle loop
communication might be better handled with the tsleep()/wakeup()
interface, so as not to unnecessairly block other processing. Whether
this is a good idea is somewhat timing-related; how long does the
device take to respond? 

> Second, the device can initiate an exchange with the host.  In this
> case, an interrupt will occur when none is expected, an exchange of
> bytes must follow (again with expected interrupts for each response
> from the device), and the host may be required to take some
> significant action as a result of the exchange.  I am much less clear
> on how to handle this situation.

Yes, this is trickier. One thing to be careful about is avoiding a
race condition between the host-initiated and device-initiated
communication; what happens if the device decides to send a byte
between when the host has set the "data wanted" flag and actually
sends the byte? Is there really no other way of determining whether a
byte from the device is a response or a new request?

What is "significant action"? Again, it's a question of timing. If you
really need to do a lot of work (digging through files or something),
or can't do it at interrupt context, or can't afford the delay of
deferring to userland, you might consider setting up a kernel process
to handle such requests (see kthread(9)). It would help to know what
this device is, as well as its expected usage model.

Hope this helps.
 
        - Nathan