[REVIEW] move tty lock/initial up in the stack

[Poul-Henning Kamp]

In message <20040619.145736.91276883.imp at bsdimp.com>, "M. Warner Losh" writes:
>In message: <61609.1087632958 at critter.freebsd.dk>
>            Poul-Henning Kamp <phk at phk.freebsd.dk> writes:
>: This patch moves the "lock/initial" facility known from sio(4) up
>: to the generic tty layer.
>: 
>: It adds two new flags to stty(1): -i and -l to manipulate the initial
>: and lock states and eliminates the tty[il]d# and cua[il]a# devices.
>
>I like this idea a *LOT*.
>
>: Subsequently I would like to move the tty/cua split up as well.
>
>How would this look to the various drivers?

Simpler.

The situation is distressingly like it were in the disk device
drivers before I headed over that way some years ago:  A lot of
stuff in the drivers that do not belong there, rampant copy&paste
and insufficient abstraction above.

In an ideal world the hardware driver would be reduced to just that,
a few simple primitives, "start", "config", "open", "close" and a
backcall "rint" with received data and modem status changes.  This
is not too unlike what Marcel have done with uart(4)

The major difference is that serial ports are rapidly headed into
the sunset whereas disks are very much a hot topic.

The pty driver is the only really interesting tty driver these days
as most terminal access is through sshd, telnetd or xterm.

Currently I see two ways to get ptys out form under giant:

1)	write an entirely new pty driver which is totally separate
	from the rest of the tty code (We don't need slip/ppp/netgraph
	support on ptys anyway).

2)	clean up the tty code enough that the pty can be deGiantized,
	paving the road for the rest of the tty drivers to get the
	same treatment, should somebody else care enough.

I havn't quite made up my mind yet, and have resorted to some general
polishing while I try to make sense of this stuff.  To some extent I
already regret getting my fingers dirty over here.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.