[ CC'd this to tech-kern, because we're talking about what I'd like
  to have in an MI "workstation console" subsystem ... HI CHRIS! :-]

On Tue, 15 Apr 1997 23:38:19 +0930 
 mike smith <miff@spam.frisbee.net.au> wrote:

 > > I.e.
 > > we have the following:
 > > 
 > >         apci0 at frodo0 channel 0
 > >                 nsutty0 at apci0
 > >         apci1 at frodo0 channel 1
 > >                 dnkbd0 at apci1
 > >         apci2 at frodo0 channel 2
 > >                 nsutty1 at apci2
 > > 
 > > ..etc.  ("nsu" == "Nat Semi UART" :-)
 > > 
 > > Dunno how practical that is at this point... we'll have to see.
 > 
 > Hmm; does the MI 'com' driver there live under the guise of 'apci'
 > or 'nsutty'?

Well, the ISA 'com' driver (it's not totally MI yet :-) currently deals
with the hardware and the tty layer.  It's not separated in the way
I'd like.  (But, then again, I'm not complaining, because that wasn't
a goal during the last revisit of the 'com' driver :-)

In a Perfect World(tm), the ISA 'com' driver would simply be a front-end
to a totally machine-/bus-independent nsuart driver, which would be
the bottom half for driving hardware.  An nstty would attach to an
nsuart to provide what we currently know as "serial port" semantics,
and would be driven by software interrupts scheduled by the hardware
layer.  Alternatively, other devices, such as keyboards (to generate
generic "wskbd" events), mice (to generate generic "wsms" events), etc.

(Hmm, in an age of gigabit networks, doesn't it seem strange that
we're still hung up on serial lines? :-)

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939