Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!cs.utexas.edu!natinst!rpp386!jfh
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.unix.wizards
Subject: Re: programmatic devices
Message-ID: <17507@rpp386.cactus.org>
Date: 29 Dec 89 06:04:13 GMT
References: <10641@ucsd.Edu> <5804@ncar.ucar.edu>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 63

In article <5804@ncar.ucar.edu> jsloan@handies.ucar.edu (John Sloan,8292,X1243,ML44E) writes:
>From article <10641@ucsd.Edu>, by brian@ucsd.Edu (Brian Kantor):
>> A programmatic device (pdev) is a program (an executable binary) living
>> in the /dev directory.  When a user program tries to open it for
>> reading or writing, a process is started that runs the program, and
>> ties its stdin and stdout to the user program open.
>	:
>> Oh, and if this isn't an original idea, pardon me.  I honestly can't
>> remember having heard of this before in the Unix world.
>
>I agree, if I had these I'd use them. And the idea can't be original,
>because I've been carrying it along in my head for a long time, and
>I know that I'm not smart enough to have thought of it myself.

I implemented a `programatic device' at a former job to give me a C/A/T
typesetter for an old-style troff and an HP 7475 plotter for the 20/20
spreadsheet the company used.

The implementation was almost too simple to mention ...

while true
do
	7475toplot < /dev/plot | tplot -Thplj | lp -og
done

where 7475toplot converted 7475 commands to tplot, tplot -Thplj
converted tplot to HP LaserJet commands, and lp -og sent raw
characters to the system laser printer.  /dev/plot was a named
pipe.  The commands would sit there waiting for another command
to open the pipe for writing.  That would happen, the input would
be read and the writers side of the pipe closed, etc.

Some what more clever would have been a multiplexed pipe driver
where each open was paired up to the next open of the opposite
flavor.  Like PTYs, except there are multiple channels per device
and successive opens create new channels.  I never saw a need for
a device which permitted read-write operations.  PTYs would work
if the TTY line discipline code was trashed.

More seriously, Brian gave a number of wonderful new ideas.  But
missed one I thought of as a neat basis for a user-level remote
or virtual file system.  Block devices.  Character devices are a
dime-a-dozen, but you can't mount a character device.

The device open and close routines would build up an ioctl packet
with just open or close.  The underlying program would get around
to performing an ioctl on the program side of the device and use
the open or close packet to set up or tear down the underlying
virtual device.

The strategy routine works similiarly, but in two steps.  First,
an ioctl packet is built giving the same information a strategy
routine always gives ;-).  The driver then waits for a responding
ioctl.  The responding ioctl packet contains the data to satisfy
the read or contains the address of the programs buffer to
accept the data for a write.

There are a few problems with this idea ...  [ And I promise I
won't suggest putting sticky bits on directories like I did the
last time ;-) ]
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org