After kicking some ideas around privately with Michael Richardson
(mcr@sandelman.ottawa.on.ca), a couple have come up that I think are
worth tossing out for general approval, derision, indifference, or
whatever other reaction they may draw.

One idea is about dialin/dialout tty lines.  I think it would probably
be possible to do proper dialin/dialout devices entirely in MI code,
that is, in the generic tty code instead of in the port-specific
drivers.

What I imagine here is three devices per tty line: a dialin device, a
dialout device, and a generic device.  You can either use the first two
or the third one; attempts to use the generic device and one of the
other two should probably fail.  (It might also be possible for the
generic device to be the same one as the dialin device, but with CLOCAL
cleared.) The generic device works the way ttys presently do.  The
dialout device does not wait for carrier, and fails on open if anyone
has the dialin device open; a process blocked waiting for carrier will
not cause a dialout open to fail.  However, while the dialout device is
open, any attempt to open the dialin device will block as if carrier
were not present.  Indeed, a process that accesses just the dialin
device cannot tell the difference between real lack of carrier and
someone having the dialout device open.  This is how my NeXT does
dialin/dialout, and it is quite pleasant to use.

Or, if you don't trust the kernel and would rather see userland locks,
you use the generic device and ignore the other two.

The second idea is to have only ptys be tty devices in the current
sense (stty settings and all), with the hardware device drivers being
optimized for high throughput to user-land and no tty goop.
Interactive logins are then handled with a user-land daemon that
interfaces between a hardware line device and a pty master half.

The real hardware drivers would then be just byte shovelers with a
little extra stuff to handle modem control lines and speed changes and
similar hardware issues.  I currently have no proposed design for the
userland interface to these things, only vague issues (for example,
should it all be multiplexed onto a single fd, or should there be one
fd for data and one for hardware control)....

I do realize these two ideas are at least somewhat incompatible with
one another. :-)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D