dws@margay.cs.wisc.edu (DaviD W. Sanderson) (04/13/91)
In article <1991Apr11.140508.9012@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: > The way Multics did things was by allowing users to plug their own input >interface library in between the terminal and whatever programs they were >running. [...] > Now, I've never programmed with streams, but I was under the impression that >it's possible to use them to do something like this. Can't the user write a >streams driver that does his line-editing [...] Well, sort of. Once installed, streams modules can be pushed and popped by an ordinary user, but since they are linked into the kernel they must be installed by root. I imagine it would be possible (since the RFS file system type does something like it) to write a special streams module that would communicate with some specifiable user-level process to perform the user-interface functions, but it would probably not be worth it. -- ___ / __\ U N S H I N E DaviD W. Sanderson | | | I N E dws@cs.wisc.edu _____| | |_____ ________ \ / \ |__/ /////__ Fusion Powered Locomotives Made to Order \____/ \__|_/ \\\\\______ (TARDIS model available at extra cost)
guy@auspex.auspex.com (Guy Harris) (04/16/91)
>I imagine it would be possible (since the RFS file system type does >something like it) to write a special streams module that would >communicate with some specifiable user-level process to perform the >user-interface functions, At least in S5R4, a streams driver of that sort, along with some added streams modules, already exists. Of course, the subsystem consisting of that stuff is called the pseudo-tty subsystem, so some members of the audience may be turned off by it, but.... (I.e., shove some editor - EMACS, Andrew's "termulator", *urk* "cmdtool", "atty", or whatever - in front of the pseudo-tty.) It's unfortunate, perhaps, that "read()" and "write()" and the like are, in most UNIX systems, treated as purely kernel functions; other systems might do the interface to special files in *user* mode, with some *internal* (and undocumented, and subject to change without notice) kernel interfaces used by the user-mode interface to special files. (As I remember, that's precisely what Multics did; Apollo's Domain systems may do something similar.) You could then have your choice between an IPC-oriented scheme like pseudo-ttys or a procedure-call oriented scheme like Multics I/O modules (and probably have endless debates on USENET over which was better). > but it would probably not be worth it. Maybe, maybe not. A tty driver of sufficient power to make me switch is probably something I would *not* want in the kernel; it'd be *too* powerful. I *do*, however, missing having "ksh"-style command editing; one of these days, I'll have to switch over to the version of the Andrew "termulator" into which I dropped a "ksh"-style implementation of ^O, or start using "atty" (which already has it), and see whether it does it for me. (I'd start using "bash" if only I could turn off its #@@$@@!#!!@ interactive search, or incremental search, or whatever the heck it's called. People who like it are welcome to it. *I* don't want to be forced to accept it as the price of admission....)