Please submit these questions to the list. Thanks, Dave
At 10:55 PM 8/12/2003 Tuesday, [EMAIL PROTECTED] wrote:
Hi Dave .....
This piece of information was really enlightening.
I have another query related to this ...
Let us suppose there is a module between the driver and the stream head. Does this phenomenon of not using putnext() from the rput routine, instead using putq() and then doing putnext() from the rsrv routine applies also to the module too.
Does a module will also have to follow the steps as followed by a driver?
Looking forward to your reply
thanks n regards .. Rajat
[EMAIL PROTECTED]@gsyc.escet.urjc.es on 08/07/2003 04:00:48 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED] cc:
Subject: Linux-streams digest, Vol 1 #365 - 6 msgs
Message: 5 Date: Wed, 06 Aug 2003 17:02:15 -0500 To: Matthew Gierlach <[EMAIL PROTECTED]> From: David Grothe <[EMAIL PROTECTED]> Subject: Re: [Linux-streams] Re: LiS questions Cc: [EMAIL PROTECTED]
Probably the big problem is that when you call putnext() from an interrupt routine LiS will get the queue lock on the upstream queue using an ordinary spin_lock call, not the irqsave version. Since you are calling from an interrupt routine this could lead to a deadlock. So it is hard to think of a case in which it is safe to do this.
In that sense you could say that this is unsupported by LiS -- at least on Linux. You can do that sort of thing on Solaris precisely because interrupts run as threads and can sleep on such lock acquisitions without deadlocking the interrupted thread. In the Solaris case it is more a property of mutexes and Solaris interrupt handling than a property of the STREAMS executive that makes this "safe" to do. If Linux ran interrupts on their own thread stacks then it would become "safe" in LiS as well.
-- Dave
At 04:22 PM 8/6/2003 Wednesday, Matthew Gierlach wrote: >Hello Dave: > > Thanks for this explanation. From this explanation I conclude > that UNIX SVR4 STREAMs drivers that actually move data upstream > from within the interrupt service routine by invoking putnext() > are not supported by LiS. Is this an accurate understanding? > If so, is this "limitation" and "deviation" from SVR4 documented > somewhere within the LiS product? > > Thanks, Matt Gierlach > >On Wed, 6 Aug 2003, David Grothe wrote: > > > At 11:55 AM 8/6/2003 Wednesday, you wrote: > > >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
