Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!rex!ames!ncar!jsloan@handies.ucar.edu From: jsloan@handies.ucar.edu (John Sloan,8292,X1243,ML44E) Newsgroups: comp.unix.wizards Subject: Re: programmatic devices Message-ID: <5804@ncar.ucar.edu> Date: 28 Dec 89 15:51:51 GMT References: <10641@ucsd.Edu> Sender: news@ncar.ucar.edu Lines: 55 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. 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@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.