Re: Christmas list for the kernel

[Vojtech Pavlik <vojtech@suse.cz>]

On Wed, Nov 23, 2005 at 11:59:27AM -0500, Jon Smirl wrote:
> On 11/23/05, Vojtech Pavlik <vojtech@suse.cz> wrote:
> > On Wed, Nov 23, 2005 at 11:37:23AM -0500, Jon Smirl wrote:
> >
> > > Before everyone gets excited, I realize that all of this has
> > > historical implications. But that doesn't mean we can't discuss
> > > possible future alternative solutions.
> > >
> > > Thinking about this for a while it seems to me that the problem is
> > > that the various apps (init, syslog) etc should not have a tty name as
> > > part of their command line parameters. Instead these apps could use
> > > ptys instead. Ptys would solve all of the race problems too.
> > >
> > > Is there any good reason (other than history) for using a device node
> > > name (tty0, etc) instead of some other naming scheme if names are
> > > needed at all?
> > >
> > > If init, syslog, etc can be converted to ptys, do we need ttys? Xterms
> > > use ptys I don't notice that they aren't connect to a fix tty name.
> > > The virtual consoles would still be 0,1,2 but do they have to be
> > > hooked to tty0, 1, 2 instead of a pty?
> >
> > The basic difference between a pty and tty is that a pty connects to a
> > program (that created it by opening the ptmx node, for example xterm or
> > ssh) on the other end, while a tty connects to the kernel doing all the
> > character drawing in the framebuffer.
> >
> > You can't easily use one instead of the other, they're very different
> > beasts.
> >
> > Of course, a way to use a pty would be to have the console
> > implementation in userspace.
> >
> > The fact that no program is on the other end of a tty is also the reason
> > why they cannot be created dynamically like ptys, there is noone to open
> > a "ttmx" to create the ttys.
> >
> > Hence, the device nodes are pre-created by the kernel, while the real
> > devices are only created on open.
> 
> I forgot about the kernel vs user space termination issue.
> 
> One solution would be to not create the tty nodes and instead modify
> init, syslog to mknod the node before using it.

You'd have to add special treatment to quite a number of programs (all
the different *getty programs, for example), for what benefit? A
slightly cleaner /dev?

> Another would be to have a little user space daemon that listened to
> the pty creation, and then mknod the tty nodes as need and pipe the
> data through.

While we in theory could have hotplug events for pty creation, this is
not a working approach, since it tries to work from the wrong side.

A pty is created when ptmx is opened (by libc). You need to pass a
tty/pty device node to syslog/getty/whatever, and not ptmx.

The daemon would be in the same situation the kernel is now - it would
have to divine when an application will be trying to open a non-existent
device node and create it juste before that.

> That would be a first step to moving to a user space
> console implementation.

No. You don't need all that for a user space console. Xterm works today.
Just specify in a config file for the userspace console which pty VT's
should it create and which programs to pass them to.

> I see now that the 64 tty devices really are there and are provided by
> the kernel. It's just that hardly anyone uses all of them and they
> clutter up /dev.
 
True. It's a tradeoff.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR