From owner-freebsd-arch@FreeBSD.ORG Sun Jun 20 08:45:09 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5817816A4D1 for ; Sun, 20 Jun 2004 08:45:09 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id B727443D5D for ; Sun, 20 Jun 2004 08:45:08 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i5K8j25s082938; Sun, 20 Jun 2004 10:45:02 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "M. Warner Losh" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 19 Jun 2004 14:57:36 MDT." <20040619.145736.91276883.imp@bsdimp.com> Date: Sun, 20 Jun 2004 10:45:02 +0200 Message-ID: <82937.1087721102@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: [REVIEW] move tty lock/initial up in the stack X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2004 08:45:09 -0000 In message <20040619.145736.91276883.imp@bsdimp.com>, "M. Warner Losh" writes: >In message: <61609.1087632958@critter.freebsd.dk> > Poul-Henning Kamp 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@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.