Re: [Linux-streams] Re: LiS questions

David Grothe Thu, 14 Aug 2003 11:35:06 -0700

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

_______________________________________________
Linux-streams mailing list
[EMAIL PROTECTED]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams

Re: [Linux-streams] Re: LiS questions

Reply via email to