Paul Kranenburg wrote:

> > Neat!  How does the new scheme work?  What needs to happen to have the
> > console (kbd,mouse) attach to a `com' (16550) device?  (I've also
> > started work on an SAB 82532 driver which will need to be integrated.)
>
> You'd have to supply some glue code, so data can travel from the
> `com' driver to the keyboard driver. For the `zs' driver, that
> glue is in `dev/sun/kbd_zs.c'.
>
> So, in principal, you could whip up a `dev/sun/kbd_com.c' (and change
> a few bits in `dev/ic/com.c' as well) and you'd have a /dev/kbd*
> interface.  Yet, I wish this wasn't even needed. I'd rather have
> a generic interface that allows one to plug a kbd or mouse driver
> into any "chip driver" that might exist without having to re-invent
> to glue over and over.
>
> I know, it's called `streams' and no volunteer has stepped forward to
> burn his fingers on it...  but it would be eminently suited to this
> task. It would probably also be a great help for implementing split
> console channels.

Streams was originally designed to solve exactly this problem, but itīs now
used in networking as well on Sys VR4 systems. FreeBSD (or is it *all*
BSDs?) has something called netgraph. Now, the name would imply this is
only for networking, and I havenīt had time to look at it properly, but
from what Iīve heard, it solves the same problems as Streams does, but in a
different way, and for networking. Just a question: might netgraph be
suitable for the task above (with tweaking, of course), just as Streams
turned out to be useful for networking?