Date: Thu, 14 Feb 2008 11:08:40 +0100 From: Ed Schouten <ed@fxq.nl> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: FreeBSD Arch <freebsd-arch@freebsd.org> Subject: Re: Proposal for redesigning the TTY layer Message-ID: <20080214100840.GQ1340@hoeg.nl> In-Reply-To: <22736.1202979772@critter.freebsd.dk> References: <20080213150500.GH1340@hoeg.nl> <22736.1202979772@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
--Bk6L21jbBNK7V1Rv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Poul-Henning, * Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: >=20 > Much of this looks very sensible, but I have a few red flags: >=20 > 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. >=20 > 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. Because I know it's impossible to fix this in the nearby future, I'm planning on re-adding support for the old /dev/pty*-style TTY's, using the old allocation model, which I'll probably call `pty_compat'. We can only hope new software will use interfaces like openpty() and posix_openpt(), so we can remove this old interface in the very far future. > Move prison checks into devfs >=20 > 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. >=20 > 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. The reason why I was thinking about this, was because devfs already stores per-device credentials (see cdevsw's si_cred field). Say, we want to expose other resources through devfs (/dev/shm/..., etc), we could also prevent access from other prisons there as well. Of course I'm willing to leave it as it is now, if we cannot come to an agreement on this. > Clists >=20 > I would just drop clists and switch to mbufs. Even though I think it's a good idea, I'm not sure how I would implement certain features the clists offer, like quoted characters for example. Ideas are welcome. :-) > Consoles... >=20 > 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. I'm planning on leaving the console code alone as much as possible. The document sometimes did mention the word `console', but in those cases I was referring to drivers which provide a graphical system console, like sc(4). > Items missing from your list: >=20 > Firmly abstract line discipline from tty code I was already planning to add the termios line discipline code outside the TTY code itself. I'll also add this to the document. Thanks for your feedback. I'll make some changes to the document based on the input I've got so far. I'll add an article to the wiki which will also contain a link to the latest version of this document. --=20 Ed Schouten <ed@fxq.nl> WWW: http://g-rave.nl/ --Bk6L21jbBNK7V1Rv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAke0EygACgkQ52SDGA2eCwX24wCdEe9hkmBhpb5xtdvHIl5gULHZ 58MAn0G5hJvGlxW5znyefhelaWcoQwuN =t3M6 -----END PGP SIGNATURE----- --Bk6L21jbBNK7V1Rv--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080214100840.GQ1340>