Stephen.Ma+netbsd-tech-kern@jtec.com.au writes:

>The underlying problem is that we have hardware devices that can act
>as both network interfaces and character mode interfaces (besides the
>zs, most ISDN cards can do both sync PPP (over HDLC), as well as async
>character-at-a-time mode (using V.120 or V.110)). I'm not entirely
>comfortable with the approach of attaching 2 or more different device
>drivers (one network, one character) to the same physical device.

That's part of the problem.  Another part of the problem is that there
are three or four different kinds of `protocols' that can go on top of
a serial device: packet-oriented network data like PPP or X.25 or
SLIP; an ASCII stream to a tty or printer or modem; or audio.
(Don't *you* want your computer to handle phone calls?)

And the ``tty'' serial devices aren't all tty-like.  There's code to
handle both Sun and DEC keyboards and mice on rs-232.  Ideally, that
code would work on any serial interface, not just a zs or a dc
(single-chip DZ-11 clone).


It doesn't take a rocket scientist to think of using streams or
bstreams to plug all these parts together.  The $64k question is
whether we'd have to start design and implementation from scratch, or
if we can get access to some of the work that's been done in this area
-- like bstreams?

(And, to foretall a different flamewar, I'm not proposing SystemV
streams, and I specifcally don't want to rework the entire IP/TCP
stack to use streams, just so we can sandwich a network device
underneath.  Unless it's demontrated not to hurt the the performance,
design, and maintainability the existing network stack.)