klemets@sics.se (Anders Klemets) (06/08/89)
I have a machine here running Bell Technologies System V/386 Rel 3.2 and I would like the ttys and pseduo-ttys to be STREAM devices. The reason why I want to do this is because I want to do an ioctl(fd,I_SETSIG,S_INPUT); i.e. I want the process to receive a signal as soon there are characters to read from the tty. On SUN 4.0 the ttys are STREAM devices, but definitely not on this System V box. Does anybody know if the ttys are STREAM devices on the Interactive Systems 386/IX OS? I guess that I could add a STREAMS driver for the ttys to the kernel, does anybody have suitable code for this? However, I would rather like to solve this problem some other way, without having to rebuild the kernel. Any hints would be appreciated. Thanks, Anders -- klemets@sics.se
vjs@calcite.UUCP (Vernon Schryver) (06/11/89)
In article <KLEMETS.89Jun8171157@tum.sics.se>, klemets@sics.se (Anders Klemets) writes: > ... > On SUN 4.0 the ttys are STREAM devices, but definitely not on this > System V box. > Does anybody know if the ttys are STREAM devices on the Interactive > Systems 386/IX OS? ... It is impossible to put a SVID-compliant tty under the SVR3.[012] stream head as it comes on the 3B2 source tapes. There is no provision for VTIM/VMIN in the SVR3 streams head, and you cannot do it below the head in SVR3 streams. Also, the SVR3 stream head believes a non-blocking read returns EAGAIN like BSD ttys and other, reasonable SV devices, instead of 0 like SVID tty's. Sun may have an advantage or two. Did they put a BSD "new tty" style driver under their streams, instead of something current-SVID-compliant? They might reasonably expect someone to listen to their requests to change the next version of the SVID. They may also have modified the stream head. I can authoritatively state that at least one SVR3 vendor is shipping a SVID-compliant streams tty driver, based on an extended streams head. You also need streams character drivers for the bottom, and some kind of line discipline module. The one I did is not small, even if the stack is 12x faster than what it replaced. It would be impossible to correctly emulate each and every bug (oops, I mean feature) of the ancient tty driver without source. Vernon Schryver vjs@calcite.uucp
les@chinet.chi.il.us (Leslie Mikesell) (06/12/89)
In article <45@calcite.UUCP> vjs@calcite.UUCP (Vernon Schryver) writes: >It is impossible to put a SVID-compliant tty under the SVR3.[012] stream head >as it comes on the 3B2 source tapes. There is no provision for VTIM/VMIN in >the SVR3 streams head, and you cannot do it below the head in SVR3 streams. >Also, the SVR3 stream head believes a non-blocking read returns EAGAIN like >BSD ttys and other, reasonable SV devices, instead of 0 like SVID tty's. AT&T 3B2's with Starlan have a streams based tty emulation for logging in over the net, and it does show exactly the problems you mention. The most common trouble is with programs that don't check for a negative return from read() after setting O_NDELAY (and why should they?). Les Mikesell
guy@auspex.auspex.com (Guy Harris) (06/13/89)
>It is impossible to put a SVID-compliant tty under the SVR3.[012] stream head >as it comes on the 3B2 source tapes. There is no provision for VTIM/VMIN in >the SVR3 streams head, and you cannot do it below the head in SVR3 streams. >Also, the SVR3 stream head believes a non-blocking read returns EAGAIN like >BSD ttys and other, reasonable SV devices, instead of 0 like SVID tty's. > >Sun may have an advantage or two. Did they put a BSD "new tty" style driver >under their streams, instead of something current-SVID-compliant? No, Sun put a System V-style driver - SVID-compliant - under a stream head that had, as you guessed, been modified to: 1) support VMIN/VTIME; 2) support BSD-style non-blocking I/O (using EWOULDBLOCK), and an S5-style non-blocking I/O that permits a streams module (such as "ldterm", the tty driver module) to say that it wants tty-style non-blocking I/O (return 0) rather than the default streams-style non-blocking I/O (return -1 and set "errno" to EAGAIN); and then put another streams module under it to translate some of the old BSD-style functions into new-style functions (the SV-style driver supports additional flag bits to give you BSD-style user interface goodies, and also directly supports some BSD-style "ioctl"s - some of which I expect to be in S5R4, such as TIOC[SG]PGRP, TIOC[GS]WINSZ, TIOCMGET/TIOCMSET/etc.). >They might reasonably expect someone to listen to their requests to >change the next version of the SVID. I expect some of the BSD functions to be in S5R4, and possibly the SVID. I expect VMIN/VTIME to be unchanged, though, from previous editions of the SVID (other than, perhaps, POSIX changes - but I think POSIX specifies the same thing as the SVID). >They may also have modified the stream head. They did. I expect S5R4 to have changes to the stream head that will enable it to support VMIN/VTIME, but I don't expect them to be the same as Sun's. I also expect it to have changes to permit it to support "old-style" non-blocking I/O, as well as POSIX-style non-blocking I/O (which is pretty much the same as the "new-style" non-blocking I/O as is supported by the S5R3 streams head - they use different flag names, so old code will continue to work in source and binary form, and new code can use O_NONBLOCK to get new-style non-blocking I/O even on ttys).