Subject: Re: Serial port issues on Sun4/260
To: None <mouse@Collatz.McRCIM.McGill.EDU>
From: Brad Walker <firstname.lastname@example.org>
Date: 01/17/1996 16:50:24
> From torek@BSDI.COM Wed Jan 17 16:01 PST 1996
> Date: Wed, 17 Jan 1996 17:00:36 -0700
> From: Chris Torek <torek@BSDI.COM>
> To: email@example.com, mouse@Collatz.McRCIM.McGill.EDU,
> Subject: Re: Serial port issues on Sun4/260
> >... What I'm suggesting is that streams gives the system the ability
> >to better buffer events ...
> Not in the sense that would help or hurt zs fifo overruns. The
> bottom-level code for dealing directly with the chip will always
> be ugly.
Agreed. There is no way around this.. Other than really tight code.
> A good streams design would help out with the rest of
> the driver, though, especially the zs<-->keyboard, zs<-->mouse,
> and zs?<-->?console hookups. (This last in particular is virtually
> unworkable in the current system -- the console can, in theory, be
> split into `screen output' and `ttya input' or some such, but the
> existing kernel is not really ready for that.) What I did (bizarre
> little `internal' open and close routines) was just a make-it-run
My point exactly. Which is to make the architecture better and using
STREAMS can help in many ways.