> STREAMS is a pretty cool I/O architecture,

Sure, but on SVR4 it broke all reasonable serial drivers  ;-)

> but its chief advantage is kind of minimized if you've already got a
> perfectly reasonable TCP/IP stack

This is quite true, but see below.

> STREAMS as a research toy could be quite interesting; STREAMS as a
> networking philosophy would probably not adequately reward the immense
> expense of doing them to specifications

I didn't think about "doing them to specifications", I just thought of
a similar powerfull mechanism.

Matthias Urlichs has a version of Linux using the NetBSD networking code
(and the scheduler, I believe). He implemented something similar to
streams in this and on top of that (or below?) got a working ISDN driver -
which is mainly limited due to Linux not having a decend tty interface
and not knowing anything about streams.

He must have gone through hell to get this working ;-)

Anyway, STREAMS are a very usefull tool for multi-headed-device drivers
like ISDN: they have a tty interface, a TCP/IP interface and probably an
IPX (oh no!) interface as well. They may have an ISO interface after 4.4
comes in.

And they have to support a variety of low-level protocol stacks, which can
be made pluggable with streams: you have a table with caller-id's and the
needed protocol-stack specification. When the interface ist called you
push the necessary modules on the stream and the caller talks to getty,
IP or whatever.

Without streams you have to do a lot of pseudo-devices (like the ppp 
interfaces) and have a lot of daemons listening on many channels for things,
which can not happen concurrently. And you have to implement all the 
ISDN protocols in one big driver - which makes it *realy* ugly.

Please don't misunderstand this: I'm not saying, NetBSD should have
STREAMS (NetBSD is a damn good OS without STREAMS!). Actualy I can
do everything I want to do with the current concepts.


Martin

------------------------------------------------------------------------------