programmatic devices

[John Sloan,8292,X1243,ML44E]

>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.

Anyway, this is a pretty object oriented approach, where you send and
receive messages (read/write) to an object (which may be a process or a
file). Thus, when you receive data, it may be coming raw from a file,
it may be preprocessed, it may be a network link to another process, or
it may be generated internally by the object. I hadn't considered
restricting the object to /dev, but given the history of UNIX, what
with pseudo-terminals and UNIX-domain sockets often being placed there,
its the logical place.

It strikes me that once the Mach-model is actually realized, that is,
most of the BSD kernel functions are moved into user-level processes,
Mach is the logical platform on which to base your pdevs. The Mach
message passing may be an appropriate mechanism to use. If you carry
this to its logical conclusion, ALL files and devices would be such
objects, and all "I/O" would be message passing.

It just occurred to me (which means this is probably really half baked)
that this is another software paradigm that really got its start in the
hardware arena. Back when I was doing real-time kernels, device
drivers, and embedded systems for a living, I realized that when I read
from a controller, I really had no idea where the data was coming from.
It was just a convenient convention that it was coming from some disk.
What with the use of solid state devices to mimic disks, and with
demand paged memory using disks to mimic memory, and with generic
controller interfaces such as SCSI servicing tapes, disks, and even
network interfaces, most of our I/O is based on these convenient
conventions. There is no reason why this couldn't be done completely in
the software arena, with object oriented languages and client-server
processes.

I dimly recall that some facility like you describe may well have
existed in some incarnation of OS/360 (MFT, MVT, SVS, MVS), from my
time in the hazy past as a systems jock on those beasts.  But (rig for
overgeneralization!) the UNIX byte-stream I/O model would make this
easier to implement, IMHO, than in the IBM block-oriented I/O model.

Neat idea.

John Sloan            NCAR/SCD             NSFnet: jsloan at ncar.ucar.edu
P.O. Box 27588        P.O. Box 3000        +1 303 497 1243   AMA#515306
Lakewood CO 80227     Boulder CO 80307     +1 303 232 8678   DoD#000011
Logical Disclaimer: belong(opinions,jsloan).belong(opinions,_):-!,fail.