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

[Kay Sievers]

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

The only difference between multi- and single instantiated would be
that you get the same and in the other case a new instance, when you
mount. If we remove the CONFIG_ option from the kernel or not, will
probably not matter that much any more.

I guess, it would involve zero userspace changes, then unlike your
marked-as-[easy] item, it is not easy at all. All initramfs generators
would need to be changed to support the new mount options that, and
they usually have no config file to add that to. We also do not add
kernel filesystems to fstab these days, fstab is almost entirely left
to the administrator's customization, and not the distribution's
defaults, so it should/can not just be added there, because it is not
in there today.

Kay
--
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/