Streams Loop-Around driver...

[rki at apollo.UUCP]

In article <1341 at cadovax.UUCP> mitchell at cadovax.UUCP (Mitchell Lerner) writes:
> Is the Loop-Around driver as shown in the the System V version 3 Streams 
> Programmers Guide in chapter 12 a way that I can do inter-process 
> communication?  I'm not sure that you can actualy open the driver from streams 
> on two separate processes (or more?) and have the driver connect the two 
> streams.  Can I use this type of Streams driver as the basis for an inter-
> process communications facility?
> 

Two separate processes can open the same minor device on such a loopback
driver and get in effect get a uni-directional communication path between
them.  All processes that concurrently open a given (major, minor) pair
share the same stream.  Frankly, named pipes are probably a better choice 
for this type of IPC.

You can easily write a driver that provides a bi-directional communication
path by pairing minor device numbers, so that each even-numbered minor
number N loops back to minor number N+1.  This requires only a very simple
handshake on opening and closing to make it work.  (This is similar to 
the scheme Dennis Ritchie used to create pipes using streams in Version 8.)

If you want to get slightly more sophisticated, you can write the driver
to allow any two minor devices to be cross-connected, using the I_FDINSERT
ioctl (a shameless hack, but we had to do something) to inform one
minor device of the identity of the other.  You could then do IPC by having one
process open two separate minor devices, connect them together via the ioctl,
and then use create a name for one of the minor devices for use by a second
process can open.  (This is essentially the way the Stream Pipe (SP) driver 
used by the RFS name server works.)

There are still other variations that can be done; for instance, you could 
implement a raw tty interface and then use the line discliple modules to 
create pty's.  If you are into connectionless IPC, you could allow each
minor device user to register a service-id, and define a message format
that includes a (destination-id, sender-id) pair that permits the
driver to route messages to the appropriate destination queue (watch
out for flow control problems with this case).  Or if you want to make
local IPC look identical to network IPC, you might write a driver that
implements the transport provider interface.

Of course you can always use the standard System V IPC stuff, which has 
the advantage of already being there and, um, working.  The best choice
of what to use really depends on the nature of the application.

Bob Israel
Apollo Computer
apollo!rki

Disclaimer: the above statement does not necessarily reflect the opinions,
beliefs, or market strategies of my employer, or of any past employer
who might consider the subject matter to be of proprietary concern.