Re: RFC: deprecating/removing the legacy mode of devpts

[Greg Kroah-Hartman]

On Sun, Apr 08, 2012 at 09:16:22PM +0200, Kay Sievers wrote:
> On Sun, Apr 8, 2012 at 20:00, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> > On 04/08/2012 12:30 AM, Kay Sievers wrote:
> >>
> >> I don't think it has much to do with udev, it follows 100%
> >> instructions from the kernel, and it does not create the device node
> >> that is in the way here.
> >>
> >> Udev does not name any device in the system since a long time. Since
> >> quite a while it has not even the code to do mknod() and requires
> >> devtmpfs. The device node part of udev these day is limited to manage
> >> device node permissions and creating additional symlinks. All device
> >> node creation happens inside the kernel itself - where it belongs -
> >> and not in userspace.
> >>
> >> If the default behaviour of /dev/pts/* should be changed, the kernel
> >> should be changed to support the multi-instance mode right away
> >> without involving userspace. We better do not require userspace to
> >> gain any knowledge about such stuff. I'm confident, that we should not
> >> add more, or require to support multiple alternative ways of handling
> >> kernel internals in userspace.
> >>
> >> So, I think we either remove the '/sys/class/tty/ptmx' device from the
> >> system, and let the devpts code create the symlink in the 'devtmpfs'
> >> filesystem, or alternatively the '/sys/class/tty/ptmx' device supports
> >> the multi-instance mode itself, instead of requiring a symlink. Such
> >> stuff belongs entirely into the kernel these day. Anything else seems
> >> to just ask for trouble.
> >>
> >
> > OK, this seems very reasonable, and something that could (and probably
> > *has to*) be done as an atomic change... maybe.
> >
> > There is no way for /dev/ptmx to support the multiinstance mode since it
> > is located outside any devpts filesystem; it *has* to be inside the
> > devpts filesystem in order to function... if that wasn't the case this
> > whole thing would have been trivial from the get-go.
> 
> In theory the open() could possibly find out to which namespace it
> belongs, but I guess the other alternative is much simpler and cleaner
> anyway.
> 
> > Greg, do you have any insights in what would have to be necessary
> > mechanics to make this.
> 
> I guess the following:
>   - remove the 'ptmx' cdev from drivers/tty/pty.c
>   - add a new devtmpfs_create_link() to drivers/base/devtmpfs.c
>   - call devtmpfs_create_link() from _init in fs/devpts/inode.c
>   - change the default of ptxmode=0 to a sane default = 0666

That all seems pretty simple.

>   - get rid of the (rather broken) idea of 'legacy' vs 'non-legacy mode'
>     mount options in the default setup; I don't think userspace should
>     ever be required to fiddle with such stuff

Hm, but if we get rid of them, what about tools that expect them to be
there?  Just silently ignore them?

I'll see if I can knock something up next week...

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/