Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!ll-xn!ames!amdcad!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: comp.unix.xenix,comp.unix.questions Subject: Re: tty watcher Message-ID: <28020@sun.uucp> Date: Tue, 15-Sep-87 06:51:10 EDT Article-I.D.: sun.28020 Posted: Tue Sep 15 06:51:10 1987 Date-Received: Thu, 17-Sep-87 02:32:09 EDT References: <4263@ozdaltx.UUCP> <15136@hi.UUCP> <1178@mtune.ATT.COM> <1180@mtune.ATT.COM> Followup-To: comp.unix.questions Organization: Sun Microsystems, Inc. - Mtn View, CA Lines: 60 Xref: mnetor comp.unix.xenix:741 comp.unix.questions:4084 > although I think you could actually do the guts of it in close to three > lines: > > /* output */ /* input */ > mblk_t *dup; mblk_t *dup; > dup = copymsg(mp); dup = copymsg(mp); > putnext(up_to_monitor,dup); putnext(up_to_monitor,dup); > putnext(down_to_device,mp); putnext(up_from_device,mp); Unfortunately, this means that *everything* going up and down the stream gets sent upstream, if you intend this to be implemented by 1) a streams module that get stuck in above the rest of the tty driver, and 2) a streams driver that implements the tap, with the two joined at the hip. This means that flush messages sent upstream or downstream will also flush the monitor, M_HANGUPs and M_ERRORs will wedge the monitor's stream, M_SIGs and M_PCSIGs will send signals to the monitoring process, etc.. It's straightforward enough to duplicate only the interesting messages with a switch statement, but it does increase the line count a bit more.... (I presume the two "putnext(up_to_monitor, ...)" calls go to different major devices, so that you can distinguish input from output. If not, the complexity goes up a bit more, as the messages need to be stamped to indicate whether they're input or output data.) > >2) Streams modules live in the kernel, and not everybody can stuff an > >arbitrary streams module into their kernel. > > True, alas, although one can in all the SVR3-based systems. Errr, can't you? Well, yeah, it's only a Simple Matter of Programming (you have to have the module first before you can insert it). You also have to have a kernel distributed as a bunch of object modules, rather than as a single executable; I could imagine some packaged systems supplying a prebuilt kernel or kernels. > >2) is the major point here; there are no tty watchers that consist solely > >of a user-mode program that drops on top of a non-hacked UNIX system. > > Yup. This is the type of problem which *ought* to be simple but which isn't > in a non-streams environment. Streams was created to be able to handle > this sort of thing - following the example above, it succeeds. Umm, no, it doesn't. I said "consist(s) *solely* of a user-mode program that drops on top of a *non-hacked* UNIX system." If the tee-junction streams module is in your kernel, then unless your vendor or some third party supplied it, either it had to be hacked up locally for some other purpose (in which case you don't have a non-hacked UNIX system) or it's part of the tty watcher (in which case it doesn't consist solely of a user-mode program. A streams-based tty driver would definitely make it much *easier* to insert this capability, since you wouldn't need to hack the tty driver code itself (which would require source in most, if not all, cases), but it still requires you to stuff code into your kernel. At some point, some vendor may, indeed, offer this streams module; however, until then, implementing a tty watcher requires kernel hacking (which, in turn, generally requires a kernel hacker). -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)