From owner-freebsd-arch@FreeBSD.ORG Thu Feb 14 09:28:20 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC05416A46D; Thu, 14 Feb 2008 09:28:20 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 5A4D313C4D1; Thu, 14 Feb 2008 09:28:20 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id BFA4617104; Thu, 14 Feb 2008 09:02:52 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m1E92qVA022737; Thu, 14 Feb 2008 09:02:52 GMT (envelope-from phk@critter.freebsd.dk) To: Ed Schouten From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 13 Feb 2008 16:05:00 +0100." <20080213150500.GH1340@hoeg.nl> Date: Thu, 14 Feb 2008 09:02:52 +0000 Message-ID: <22736.1202979772@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Robert Watson , Remko Lodder , Wojciech Koszek , FreeBSD Arch Subject: Re: Proposal for redesigning the TTY layer X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2008 09:28:20 -0000 Much of this looks very sensible, but I have a few red flags: The current PTY implementation (both /dev/pty* and /dev/pts/*) suffers from the problem that a simple stat() on a nonexistent device will already create the device, even if the user has no intention to use it. Last I worked on this, there were several applications in ports that broke if this didn't work that way. You would have to be prepared to hunt down every single bogo_openpty() function in ports if you carry this change through. Move prison checks into devfs They do not belong in DEVFS, since that would require DEVFS to know far more about the device semantics if the individual drivers than it ever should. You can put it in the generic tty layer if you want, that would be emminently sensible, but DEVFS is the wrong place for it. Clists I would just drop clists and switch to mbufs. Consoles... Consoles are not ttys and ttys are not consoles. They may share hardware, but that does not make them the same thing. I have analyzed the console situation in detail on the arch@ mailing list long time ago, and you should read that analysis before you touch the console code. Items missing from your list: Firmly abstract line discipline from tty code -- 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.