voss@s.cs.uiuc.edu (10/20/89)
I am just starting a small project to write a "tty" driver for a research operating system. I got the word today that I should NOT clone the BSD/SYSV versions. Quote "no IOCTLs". Basically, I have an almost clean slate to work with. Functionally, I intend to base my work roughly on BSD `man 4 tty`. (Because a friend will be implementing a Unix compatibility mode on top.) The questions: Is there anything NOT in `man 4 tty` that you think I should put in my driver? Is there anything IN `man 4 tty` you think I should NOT put in my driver? Why? Feel free to get slightly crazy, I'ld rather discard, than neglect an idea. (WARNING: You may be using my driver someday, better speak up now! ;-) If you want to get real crazy, or real long. INTERNET: voss@cs.uiuc.edu
allbery@NCoast.ORG (Brandon S. Allbery) (10/24/89)
As quoted from <216100015@s.cs.uiuc.edu> by voss@s.cs.uiuc.edu: +--------------- | I am just starting a small project to write a "tty" driver for a research | operating system. I got the word today that I should NOT clone the BSD/SYSV | versions. Quote "no IOCTLs". Basically, I have an almost clean slate to | work with. Functionally, I intend to base my work roughly on BSD `man 4 tty`. | (Because a friend will be implementing a Unix compatibility mode on top.) | Is there anything NOT in `man 4 tty` that you think I should put in my driver? | Is there anything IN `man 4 tty` you think I should NOT put in my driver? +--------------- Consider starting with the System III/V setup instead. But use your chance to do it better. (1) Implement at least some of the Berkeley "new tty" stuff as part of the "local flags". (2) The System III/V setup is much more orthogonal than the Berkeley one... but it still has warts. Now is a good time to correct them and make it *fully* orthogonal. (3) Speaking of which: kindly separate VMIN and VTIME from VEOF and VEOL. Job control (hacks...) can be added onto such a structure if you choose. The maelstrom of V7/BSD arrangements (separate ioctls for four different "kinds" of items, which should be reduced to AT LEAST two and possibly a USG-ish single structure -- although that is arguable) is a bit ridiculous, in my opinion. Whatever you do, consider that you are possibly building for the future and *do* *it* *right*. Both the current Unix tty interfaces have problems which cry out to be addressed. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@NCoast.ORG uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp 161-7070 (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie), comp-sources-misc@backbone [comp.sources.misc-related mail should go ONLY to comp-sources-misc@<backbone>] *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)*
decot@hpisod2.HP.COM (Dave Decot) (10/25/89)
Make sure it is possible to implement POSIX.1 (IEEE Std 1003.1-1988) Chapter 7 on top of whatever you come up with. Dave
roy@phri.UUCP (Roy Smith) (10/25/89)
In article <216100015@s.cs.uiuc.edu> voss@s.cs.uiuc.edu writes: > anything NOT in `man 4 tty` that you think I should put in my driver? One of my long-time wants for a tty driver is a 256-long look up table. This is probably a feeping creature, but like all such creatures, it in itself should be trivial to implement (i.e. it's all the *other* creatures which make the kernel so bloated!) Each input character taken off the raw queue is looked up in the table to find out what action should be taken. The two possible actions I have in mind are "echo and buffer in the cooked queue" and "don't echo, put on cooked queue, and cause an input break (i.e. make read(2) return)". You should also be able to cause an input break after a certain number of characters have been typed. The idea is to allow programs like emacs to run in a mode slightly more intelligent than the traditional raw or cbreak modes, but still get at every character it has to when it has to. For most things (i.e. plain printing characters which have not reached the end of the line yet) you can let the kernel do the echoing. Any time an escape character is typed, or the end of a line is reached, you let emacs get control again and decide what needs to be done. Of couse, you need an ioctl to let the user program load its own 256-byte long lookup table. > Is there anything IN `man 4 tty` you think I should NOT put in my driver? Yes, get rid of the proliferation of control structures pretending to have v6 and v7 backwards compatability and start again from scratch. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"
voss@s.cs.uiuc.edu (10/25/89)
> Quote "no IOCTLs".
Clarification: No, I am not writing a "stateless" driver. The "boss" just
thinks the ioctl() interface is over over over loaded.
(It is rather hard to disagree with him there!)
At the very least, I'll be splitting ioctl's functionality in two.
One for data into the driver, the other for data from the driver.
------------------------------------------------------------------------------
The most popular comment via E-mail has been:
"Base your driver on the POSIX 1003.1 standard instead of Bsd 4.3 `man 4 tty`"
I just finished reading appendix C. Thanks for the suggestion, it
clarified some things, and definitely saved me from some misfeatures.
------------------------------------------------------------------------------
The second most popular comment:
Set special modes to characters, instead of characters to special modes.
An example was having 'stty erase' bound to BOTH backspace and delete.
I'm definitely planning to do this in a big way. I'm writing in C++, and
am effectively going to make ever character an object.
(No, I'm not going to call a constructor for every character typed,
only one instance of 'A' for example.)
==============================================================================
Follow up question:
I haven't "slept on it" yet, but I was thinking this afternoon.
Perhaps THE MOST COMMON USE of ioctl calls is something like:
get current state
set new state
restore saved state
This leads to what may be the most common problem with ttys,
the "restore" step being skipped.
(I know the tcsh even does "tty sanity" checking.)
The solution I am considering, in effect implement a copy-on-write
style system. Effectively, each process would have its very own
internal TTY state. The initial state would be inherited from the parent.
When all processes using a state have died/closed(tty) the space would
be reclaimed. Some information would obviously need to be shared,
but the current "raw, cbreak, cooked" state could certainly be unique.
(The state information would be held in memory subject to swapping.)
[I'ld add an escape, ctl(DONT-COPY-ON-WRITE, 1) for things like stty.]
What do you think, sound like a good idea?
Bill Voss
INTERNET: billvoss@uiuc.edu or voss@cs.uiuc.educhip@ateng.com (Chip Salzenberg) (10/26/89)
According to allbery@NCoast.ORG (Brandon S. Allbery): >As quoted from <216100015@s.cs.uiuc.edu> by voss@s.cs.uiuc.edu: >+--------------- >| I am just starting a small project to write a "tty" driver for a research >| operating system. >+--------------- > >Consider starting with the System III/V setup instead. Seconded. >(3) Speaking of which: kindly separate VMIN and VTIME from VEOF and VEOL. And make all control characters optional. As in, "stty intr none". -- You may redistribute this article only to those who may freely do likewise. Chip Salzenberg at A T Engineering; <chip@ateng.com> or <uunet!ateng!chip> "'Why do we post to Usenet?' Naturally, the answer is, 'To get a response.'" -- Brad "Flame Me" Templeton
natei@sco.COM (Nathaniel Ingersoll) (10/28/89)
Talking about writing a new tty driver for some system: In article <254641C0.4960@ateng.com> chip@ateng.com (Chip Salzenberg) writes: > >And make all control characters optional. As in, "stty intr none". Try setting the control character to -1 to undefine it; in system V use % stty intr ^- as per the stty(1) man page. -- ________________________________________________________________________
lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (10/31/89)
In article <4055@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >In article <216100015@s.cs.uiuc.edu> voss@s.cs.uiuc.edu writes: >> anything NOT in `man 4 tty` that you think I should put in my driver? > > One of my long-time wants for a tty driver is a 256-long look up >table. This is probably a feeping creature, It definately is. Handling 16 bit characters is going to require a bit more than 256 bytes ... To make this truly useful, you would want to specify a character to function mapping, with an ioctl to allow the user to plug in a user level function address which would be called when that particular character is encountered in the input queue (or to specify a kernel routine to handle common cases). You could (perhaps) save on space by using a dynamic hash table to map the characters to their routines, by having a mappable default action for any character not found on the hash chain This is starting to get ugly. It sounds like we just reinvented SVR3 streams ... -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,decwrl,lsuc}!atha!lyndon || lyndon@cs.AthabascaU.CA The Connector is the Notwork.
chip@ateng.com (Chip Salzenberg) (10/31/89)
According to natei@sco.COM (Nathaniel Ingersoll): >In article <254641C0.4960@ateng.com> chip@ateng.com (Chip Salzenberg) writes: >>And make all control characters optional. As in, "stty intr none". > >Try setting the control character to -1 to undefine it; >in system V use > % stty intr ^- > >as per the stty(1) man page. The stty(1) man page lies. The command "stty intr '^-'" doesn't make the interrupt character undefined, it makes it 0xFF. If I have a terminal that generates 0xFF, or if line noise is interpreted as 0xFF, then I get a SIGINT. I renew my request. I want an "stty intr none" that _works_. -- You may redistribute this article only to those who may freely do likewise. Chip Salzenberg at A T Engineering; <chip@ateng.com> or <uunet!ateng!chip> "'Why do we post to Usenet?' Naturally, the answer is, 'To get a response.'" -- Brad "Flame Me" Templeton
peter@vd.volvo.se (Peter Hkansson) (11/10/89)
In article <1093@toro.UUCP> nick@toro.UUCP (Nicholas Jacobs) writes: >What about having the ability to indicate perhaps via the getty invocation >in the /etc/inittab a table of characters to use for I/O (essentially an >equivalence table of sorts). Although this wouldn't handle the problems with >JIS codes and such, perhaps it could make some of the issues with just >the American and European versions of ASCII easier to deal with? > ** stuff deleted ** Yes folks this is done by IBM in the AIX for the RT. Its made by defining one mapping for incoming characters and one for outgoing ones. This is enabled on a port by port basis where the mappings are plain textfiles with 256 lines and two columns. This simple mecanism enables terminals to be intermixed and still use the same (internal) representation of 8 bit character sets. Of cource it does not handle 16 bit characters and it does increase the loading but it io really a nice feature. You could wish terminal maker to do this too ..(Texas did in thier 745 remember ??)