Hi Dave:
I also have one additional question.
What are the technical reasons that: "One good practice is not to have such a routine call putnext(). Have it call putq() instead and let the service routine perform the STREAMS related work." What technically occurs by invoking putq() that will make this viable over the straight invocation of putnext()?
Doing a putnext from interrupt level can set off a chain of events that may take some time to execute. Meanwhile there is some wholly unrelated interrupt level lock being held by the driver code that called your code. The driver that took the interrupt does not get control back for quite some time and may not be able to tend the hardware.
Using putq allows deferred execution of the real work and returns to the driver right away. It is really the STREAMS equivalent of the tasklets or bottom half processing in native Linux.
-- Dave
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
