[ On Mon, September 11, 1995 at 18:20:01 (-0700), Jonathan Stone wrote: ]
> Subject: STREAMS (long) [was Re: question about cdevsw & interrupts]
>
> To quote DMR(?), talking about the difference between Research Unix
> streams and Sysv STREAMS, "streams does not mean the same thing when
> shouted".

If you're comparing the streams Ritchie describes in AT&T BLTJ v63#8
with SysV STREAMS, then you're looking at two different generations and
very different implementations of the same concepts.

The SysVr3.2 STREAMS solve many of the problems Ritchie noted with his
original design (including implementation of a true multiplexer and
mechanisms to avoid panics during resource starvation periods); and
SysVr4 (SVID-III) STREAMS goes further to solve a few more of those
problems.

To quote Ritchie's footnotes from "A Stream Input-Output System", UNIX_
Research_System_Papers_Tenth_Edition_V.II (Bell Labs, 1990):

	AT&T's UNIX System V Release 3 introduced a reimplementation (in
	a commercially available system) of the streams mechanisms
	described here.  This version was incomplete; for example, it
	did not contain a new terminal-handling scheme.  UNIX System V
	Release 4 is intended to complete the streams implementation.
	The System V version of streams is called STREAMS, and though
	considerably more ornate, is based on the same ideas that are
	described here.

SysVr4 does indeed complete the STREAMS implementation as the ``one true
way'' to do tty handling and networking.

	Subsequent Research versions of the system still do not have a
	general stream-multiplexing scheme built into the kernel, while
	the System V streams implementations do.  We have not found any
	applications that suffer from the lack of stream-multiplexing.

They get around the lack of a mux by using user-level mux processes.

Note the paper "Multiprocessor Streams for Plan 9" [Presotto] includes
some performance results which tend to indicate that SysVr3 STREAMS
pipes are almost as good for throughput on a uniprocessor machine,
though they may have slightly higher latency.  Unfortunately direct
comparisons on the same hardware were not done.

> 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.

Note that Plan 9 continues to use the streams concept (though in a
process based implementation, vs. the 8th Edition co-routine approach).

Further the xKernel by Larry Peterson also uses a streams-like
implementaion to study the decomposition of network protocols and for
RPC.

The streams ideas are not only "nice", but have a certain elegance that
I don't think you'll see going away any time soon....

> 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) ?

I'm not sure telnet is a good example of a problem to be solved with
Eighth Edition streams, STREAMS, bstreams, Plan 9 streams, or any other.

However streams concepts make implementations of network protocol stacks,
esp. when multiple different transports end up using the same physical
layer, far more elegant.

> 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'd agree with that 100%, STREAMS, bstreams, streams, or whatever....

Though, just getting rid of the old clist based tty code would be a big
win, I'd think.

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>