Subject: Re: Serial port issues on Sun4/260
To: None <mouse@Collatz.McRCIM.McGill.EDU>
From: Brad Walker <bwalker@musings.com>
List: port-sparc
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: bwalker@musings.com, mouse@Collatz.McRCIM.McGill.EDU,
>         port-sparc@NetBSD.ORG
> 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
> hack.

My point exactly. Which is to make the architecture better and using
STREAMS can help in many ways.

-brad w.