Date: Thu, 14 Feb 2008 09:02:52 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Ed Schouten <ed@fxq.nl> Cc: Robert Watson <rwatson@freebsd.org>, Remko Lodder <remko@freebsd.org>, Wojciech Koszek <wkoszek@freebsd.org>, FreeBSD Arch <freebsd-arch@freebsd.org> Subject: Re: Proposal for redesigning the TTY layer Message-ID: <22736.1202979772@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 13 Feb 2008 16:05:00 %2B0100." <20080213150500.GH1340@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?22736.1202979772>