What I write below is a bit strongly worded, and I'm not
sure I want to send it to the whole list yet.  If I'm missing
the gist of what you want to do, or my critique is off-base,
please let me know.


>I'm interested in doing something like SysV STREAMS. And the reason
>is that I find it easier to unify the tty & networking sub-systems
>using STREAMS. Also, STREAMS makes things a little easier when you
>want to add/replace different layers of functionality.


Speaking purely personally, I hope NetBSD doesn't get SystemV streams,
or any really close approximation.  The performance is, at least for
real SystemV, appalling.  Serious Unix vendors (e.g., Sun) typically
take SysV streams and rip out the STREAMS code for tcip/ip, and use
special "fast path" calls that jump directly into a BSD-style stack.
The performance improvement is significant; for some cases I'm told it
saves a context switch on each STREAM-crossing boundary.

To quote DMR(?), talking about the difference between Research Unix
streams and Sysv STREAMS, "streams does not mean the same thing when
shouted".

Also, I think the world has changed since streams were proposed --
i.e., the days of VAX 11/785s, and maybe 8600s (4 mips?)  Machines
have got faster, networking stacks have got larger, and the relative
advantage of plugging modules together in the kernel has decreased.
Streams is a nice idea, but given Telnet options for Kerberos
authentication and encryption, I think it's far from clear how useful
streams really are. Do we _really_ want Krb4 or Krb5 authentication
inside the kernel as a STREAMS module?  And if not, how useful is
STREAMS if it can't handle what used to be the exemplar of arguments
why STREAMS was a good idea (namely, telnet) ?

Of course there are other reasons why one may wish to use STREAMS.
I'd argue that, whatever the reason, there's little point until
one converts _all_ the networking and tty code to use STREAMS.
I think if that happened to NetBSD, I'd go look for another OS.