Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!mentat!blc
From: blc@mentat.UUCP (Bruce Carneal)
Newsgroups: comp.unix.wizards,comp.unix.xenix
Subject: Streams development tools
Message-ID: <123@mentat.UUCP>
Date: Tue, 22-Sep-87 19:21:33 EDT
Article-I.D.: mentat.123
Posted: Tue Sep 22 19:21:33 1987
Date-Received: Thu, 24-Sep-87 06:56:08 EDT
Reply-To: blc@mentat.UUCP ()
Organization: Mentat Inc., Camarillo, CA
Lines: 65
Xref: mnetor comp.unix.wizards:4413 comp.unix.xenix:798

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.  We implemented this in four parts:

	1)  A kernel resident streams module that registers processes to
	    receive messages indicating open() requests on previously
	    unavailable modules/muxes/devices.  This involves a module
	    that overwrites dummy entries in the fmodsw or cdevsw.

	2)  A splice module to reroute traffic to/from kernel based
	    place holder queues instantiated when one of these
	    registered modules/devices is opened. 

	3)  A streams environment that will run in the registering
	    processes.

	4)  A simple interface library to hide the details of registration
	    and message dispatch from the streams developer.  In our
	    implementation, when the routine xm_main() is called, all
	    non-conflicting devices/muxes listed in a process local
	    fmodsw/cdevsw table are registered with the kernel and a
	    data driven grand loop is entered.

Using these facilities you can add or delete streams modules/muxes/drivers
at will from a running kernel with minimal risk.  If a streams process
crashes, the splice module instantiation representing a module inside the
kernel will close.  If there are outstanding clients of the module/mux/driver
they can be signalled with an error, afterwhich the splice module
unregisters the module and you're ready to try again as soon as you
find the problem.

We call this collection of facilities XM (eXternalized Messages).
We use XM to develop all our non-hardware specific streams modules, from
simple monitors to full protocol stacks.  XM was moderately difficult
to get "right", but the payoff in development and debugging time is
substantial.  Streams programming is almost as easy now as simple application
programming.  To move modules in or out of the kernel without change, you *do*
have to follow the streams programmer guidelines given in the V.3 red books,
but that's really not too restrictive.  All of our non-hardware
modules/muxes/drivers run unchanged in either environment.

On the negative side, a message takes a performance hit of about 5X
during it's first transition from the kernel to a process and, optionally,
back again.  If multiple processes are involved, with no stream queue
neighbors being handled by the same process, a message will burn a lot
of time shuttling around between address spaces.

If you'd like the technical documentation on XM drop me a note.  If you don't
handle LaTeX I'll need your surface mail address.

PS:  For the masochists in the crowd, this stuff runs on 286 based
     X*nix as well as on V.3 machines.

-------------------------------------------------
	Bruce Carneal
mail:	Mentat Inc., 663 N. Las Posas #112, Camarillo CA 93010
phone:	805-987-3950
uucp:	...!uunet!mentat!blc