From owner-freebsd-questions Mon Jan 22 10:23:54 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA03306 for questions-outgoing; Mon, 22 Jan 1996 10:23:54 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA03300 for ; Mon, 22 Jan 1996 10:23:51 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA15509; Mon, 22 Jan 1996 11:13:09 -0700 From: Terry Lambert Message-Id: <199601221813.LAA15509@phaeton.artisoft.com> Subject: Re: streams To: chuckr@glue.umd.edu (Chuck Robey) Date: Mon, 22 Jan 1996 11:13:09 -0700 (MST) Cc: terry@lambert.org, wollman@lcs.mit.edu, leisner@sdsp.mc.xerox.com, freebsd-questions@FreeBSD.org In-Reply-To: from "Chuck Robey" at Jan 20, 96 04:49:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-questions@FreeBSD.org Precedence: bulk > Terry, I lifted that analogy from Heidemann's paper, where he draws it. > He's the author of stackable FSs. Besides, I think you take the analogy > too far; any analogy, if taken far enough, fails. John drew the analogy to explain what the heck his strange looking animal was. I thought you were drawing the anaology the other way to justify it on the basis of "if it's good for A, it's good for B". > From Garrett's comments and yours, and they make sense, using streams for > a basis of networking is _bad_. OK, but if I was proposing a streams > interface for character io only (maybe including ppp), would your > comments still be accurate? I agree that the standard Streams architecture can be changed to be generally more usable as other than a prototype environemnt. But in so doing, you would lose a lot of the basis for Streams as opposed to, for instance, X-kernel (where they have already done the change work). For character I/O (as Garrett points out), the overhead is much less significant than the inherent delays in character I/O because of what it is talking to (slow interfaces and slow humans). It's interesting to note that the more recent versions of Solaris have bypassed much of this and places telnetd/rlogind functionality directly in the kernel a kernel threads. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.