programmatic devices

[Robert Cousins]

In article <17507 at rpp386.cactus.org> jfh at rpp386.cactus.org (John F. Haugh II) writes:
>In article <5804 at ncar.ucar.edu> jsloan at handies.ucar.edu (John Sloan,8292,X1243,ML44E) writes:
>>From article <10641 at ucsd.Edu>, by brian at 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.
>
>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.
>
>John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
>Ma Bell: (512) 832-8832                           Domain: jfh at rpp386.cactus.org

Actually, there exists a way to do all of this under most UNIXs today.
Using the mount(2) call (or its logical equivalent) for NFS mounts, it 
is possible to register a user level program as an NFS server.  The server
would recieve V-node based operations and would appear as a file system
to the host. The `pdev' operations could be performed by simply piping 
data through a defined resource program (many of which are already written).
Special device I/O such as reading foreign file systems (MS-DOS, CD-ROM (hsg,
iso 9660), Appleshare, etc.) could be built in this way. A very useful
fact is that this server would be able to implement "virtual directories"
which could contain all manner of things from various services to virtual
devices (NFS doesn't support devices directly, but they can be fudged somewhat)
and configuration information. 

Since systems can support multiple servers, there is no reason why any 
one server must be omnipotent.  Use one for Pdevs, one for file systems, 
one for Comms, one for streams operations which are too bizarre to worry 
with otherwise.  Once the base code for installing oneself and mounting 
oneself is done, the remainder should be simple.  (Sounds like a good 
thing to put into a library, too.)

Lastly, the interpretation of security is done by the server. This
translates into extreme flexability for some touch applications. Picture,
for example, a special "database filesystem" which magically keeps all
information in its files in the proper order.  Different files in the
same directory are actually the same table with different views as
defined by the administrator.  However, when some users attempt to 
access some views, they succeed, while others fail.... The possibilities
here are many.

Just more fuel for the fire.

Robert Cousins
Dept. Mgr, Workstation Dev't.
Data General Corp.

Speaking for myself alone.