I have rewritten the flush code in LiS for version 2.12. It now works
correctly, as near as I can tell via inspection and testing. It implements
the band 0 exception for doing flushband(0).
While working on this I noticed that Solaris does NOT implement the
exception for band 0. Their flush routine treats band 0 the same as any
other band. Thus, it will flush M_PCPROTOs because the b_band of those
messages is zero. There is even a comment to that effect in the code.
Bottom line is that LiS flushing will be according to the AT&T SVR4 STREAMS
spec, but will differ from what Solaris does in this one detail. It is
something to be on the lookout for in case anyone has drivers ported from
Solaris that depend upon this subtlety of the flushing rules.
-- Dave
[EMAIL PROTECTED] wrote:
> Hello,
>
> I am using LiS 2.10 and I suspect a bug in Stream head M_FLUSH
> processing.
> When the Stream head read queue contain a M_PCPROTO message, and a
> driver issue a M_FLUSH message on this read queue, M_PCPROTO message is
> flushed but the STRPRI flag is kept up so another M_PCPROTO cannot be
> sent on this queue...
> I think the STRPRI flag must be cleared after flush if the first message
> in the queue is not a M_PCPROTO message...
>
> I have another question :
> "Are high priority messages flushed when flushing band 0 ?"
> After reading the code, I think so, but I don't understand why flushing
> band 0 cause all messages to be flushed. In fact, there is no difference
> between flushq and flushband 0 ..??
>
> Best regards.
>
> Laurent Dufour.
_______________________________________________
Linux-streams mailing list
[EMAIL PROTECTED]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
