Asri-unix.522 net.unix-wizards utcsrgv!utzoo!decvax!ucbvax!hpvax!sri-unix!sdcsvax!jmcg@Berkeley Thu Jan 14 21:29:16 1982 line disciplines considered inadequate I think the implementation of tty devices under UNIX is seriously flawed. The question about line disciplines from MBM@MIT-XX points to part of the problem, but I believe the difficulties lie even deeper. There is a hierarchy of services provided by the system to support files on disk devices (and, a bit ridiculously, on tapes) ranging from the "raw" disk at the low level to "normal" file access, complete with pathname parsing. This hierarchy is pretty clean. The services provided to support files on serial devices like RS232 ports are a hodgepodge. Details such as the desired parity are handled at the same level as tab expansion and terminal-dependent, character-dependent delays. There are many contributing causes for the confused state of things: users demand a much larger variety of services from `tty' files; the actual devices at the other end of the line can be another computer, a human being, a line printer, plotter, etc.; terminal manufacturers have been marvelously inventive. The approach to a solution that I would like to see can be termed "stackable line disciplines"--this concept was mentioned by Bill Joy several Usenixes ago. I don't know how they would be controlled, how to get around the performance problems, etc., but it would work something like this: At the lowest level you would have the "raw" device file. The user would typically NOT open this device any more than he typically opens a raw disk device. The raw device provides for characters to move in and out plus a hook which would allow a "term" file to be attached to the device. A "term" file would still act pretty much the way "tty"s do now. What would be different is the kernel's implementation. There would typically be a list of line disciplines associated with the tty and each line discipline would get a whack at the data. I envision these line disciplines as being very simple. Some examples: an echo discipline would arrange for the character to be echoed, a delay discipline would check outgoing characters to see if a delay was required, a delimiter discipline would check an incoming character to see if it requires some action (CR, INT, erase, kill, etc), and a possibly separate discipline will look up the action bound to that character and perform it. At the bottom of it all would be the "attach" discipline which would deliver characters between the "raw" file and the "term" file. I think this approach has lots of advantages. Implementing virtual terminals should be easier. Whatever MPX files are good for, their discipline could be inserted into the stack. It should be possible to create disciplines with actions implemented as functions in a user process (an EMACS discipline?). Jim McGinness ucbvax!sdcsvax!jmcg UC San Diego--Chemistry ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.