Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!ginosko!cs.utexas.edu!uunet!dino!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!s.cs.uiuc.edu!voss
From: voss@s.cs.uiuc.edu
Newsgroups: comp.unix.wizards
Subject: Re: TTY, speak now, or forever
Message-ID: <216100017@s.cs.uiuc.edu>
Date: 25 Oct 89 16:34:28 GMT
References: <216100015@s.cs.uiuc.edu>
Lines: 52
Nf-ID: #R:s.cs.uiuc.edu:216100015:s.cs.uiuc.edu:216100017:000:2273
Nf-From: s.cs.uiuc.edu!voss    Oct 24 20:12:00 1989


> 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.edu