Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!oddjob!gargoyle!ihnp4!homxb!mtuxo!mtune!jhc
From: jhc@mtune.ATT.COM (Jonathan Clark)
Newsgroups: comp.unix.wizards,comp.unix.xenix
Subject: Re: Streams development tools
Message-ID: <1313@mtune.ATT.COM>
Date: Tue, 22-Sep-87 23:38:33 EDT
Article-I.D.: mtune.1313
Posted: Tue Sep 22 23:38:33 1987
Date-Received: Sat, 26-Sep-87 00:45:50 EDT
References: <123@mentat.UUCP>
Reply-To: jhc@mtune.UUCP (Jonathan Clark)
Organization: AT&T ISL Middletown NJ USA
Lines: 27
Xref: mnetor comp.unix.wizards:4430 comp.unix.xenix:803

In article <123@mentat.UUCP> blc@mentat.UUCP () writes:
>I've been watching the "streams" discussion for the last little while
>with various people making statements about how easy/difficult it is
>to do streams development.  The nicest way we've found to do streams
>development is outside the kernel.

There's no reason that I can think of in 30 seconds apart from the need
to access I/O space that *forces* stream modules to run in the kernel
environment and address space. They would typically run *faster*
there, because the support environment was designed to be the kernel.

I can certainly foresee in the future having a version of UNIX which
runs in four rings: user, shared libraries, streams, and kernel. Five
rings if you put device drivers between streams and kernel. Six if you
stick the syscall interface somewhere appropriate. 7 and 8 anyone?

Conversely, running streams in user space would be useful mostly in
the debugging phase of a project. Once the stream modules work (a
Simple Matter of Programming, as Guy Harris said recently), you could
put them into the kernel and forget about them. Saves all that
tedious rebooting and disk rebuilding when your driver goes amok with
the kernel buffer pointers...
-- 
Jonathan Clark
[NAC,attmail]!mtune!jhc

The Englishman never enjoys himself except for some noble purpose.