Subject: Re: Serial port issues on Sun4/260
To: None <port-sparc@NetBSD.ORG, mouse@Collatz.McRCIM.McGill.EDU>
From: Brad Walker <bwalker@musings.com>
List: port-sparc
Date: 01/17/1996 13:23:53
> Date: Wed, 17 Jan 1996 13:32:54 -0500
> From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
> To: port-sparc@netbsd.org
> Subject: Re: Serial port issues on Sun4/260
> Cc: bwalker@musings.com
> 
> >> [T]he zs chip will never wiggle any signal to get the modem to shut
> >> up.  This means you must never overflow the zs chip's fifo.
> > This is a great reason for implementation of STREAMS..
> 
> How can STREAMS help any?  No software can give the hardware
> capabilities it doesn't have.
> 

I'm not suggesting that streams (ie. i do this in lower case to make
the typing easier) give the hardware more that it's capable of. What
I'm suggesting is that streams gives the system the ability to better
buffer events (ie. async events) that happen when the system is not
really able to handle things.

For example, if your application has a serial port open and data is
coming in but the read system call hasn't been called from the
application, the driver is still going to call the receive intr.
routine.  If you have data flowing in a high baud rate then you need to
place it somewhere. I've just taken a look at the zs.c driver and the
current model is antiquated. Also, dealing with flow control is better
in the streams model. Streams has it's problems also. And this would be
where I or whomever could make a decision to do things differently.
All, I'm suggesting is that using streams is a better model for
unifying serial communications.

Also, streams gives you the ability to do some neat things like
modules.

-brad w.