Proposal for redesigning the TTY layer

[Ed Schouten]

Hello Poul-Henning,

* Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> 
> 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.

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
> 
> 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.

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
> 
> 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...
> 
> 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:
> 
> 	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.

-- 
 Ed Schouten <ed at fxq.nl>
 WWW: http://g-rave.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20080214/8d2162c5/attachment.pgp