Charles M. Hannum wrote:
> On Thu, Jun 15, 2006 at 12:54:53PM -0700, Garrett D'Amore wrote:
>   
>> There is a ring buffer in the middle that is used to transfer between
>> the hard and soft interrupts, but if the soft interrupt doesn't get
>> timely enough service, then even that will fill up.
>>     
>
> It certainly will.  And that's better than dropping random intermittent
> bytes in the hardware interrupt handler -- because in that case you get
> livelock with PPP and SLIP.
>
> Which is to say, you haven't understood the purpose of the flow control
> architecture in the driver, so please don't mess with it.
>   

I'm not "messing" with it.  In fact, I've not touched it.  I've just
heard some complaints from users, and as the most recent person to touch
com(4), I think some folks I heard were asking me to investigate further.

What I had said earlier was that at least some hardware might not need a
split between the hard and soft interrupt handlers.  I think a ring
buffer is likely still required just to account for the fact that
userland consumers are likely to run slower *yet*.  I've never suggested
removal of the ring buffer.  (I have suggested that for very fast data
rates on slower h/w, it *might* make sense to increase the size of that
buffer.  But that depends on whether we are seeing ibuf floods or silo
overflows.  I still don't know that because I've not see any of the
problems.)

> As for zs vs. com, notice that their guts are almost identical.  Maybe
> this is because I retooled both of them at the same time...
>   

Maybe.  I should look at it in more detail.  It looks like there are
enough differences that making zs.c just another instantiation of com(4)
might be a bad idea.  (The separate mouse/keyboard streams at least
comes to mind.)


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191