RFC: deprecating/removing the legacy mode of devpts

RFC: deprecating/removing the legacy mode of devpts

[H. Peter Anvin]

Currently, devpts supports a legacy mode where only one instance exists.
 For backwards compatibility, this is also the default mode, but the
right thing should be to migrate everyone over to the "newinstance" scheme.

However, it is increasingly clear that that is not happening; neither
the distros nor udev support this by default at this point.

I think it might be time we set a sunset date for the legacy mode,
probably around kernel 3.9 at this point.

The big change is that /dev/ptmx instead of being a device node should
be a symlink to /dev/pts/ptmx, which is then either chmodded to the
proper permissions, or given proper permissions via the ptmxmode mount
options to devpts.  The latter is probably preferable from a technical
point of view since it doesn't create a "gap".

As such, I would like to suggest the following:

1. For 3.5, add this to feature-removal.txt.
2. For 3.6, remove CONFIG_DEVPTS_MULTIPLE_INSTANCES as a configuration
   option, and printk a warning if devpts is mounted without the
   "newinstance" option.
3. For 3.9 remove the legacy support including support for a ptmx node
   outside the devpts filesystem.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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

[Alan Cox]

On Sat, 07 Apr 2012 11:36:26 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:

> Currently, devpts supports a legacy mode where only one instance exists.
>  For backwards compatibility, this is also the default mode, but the
> right thing should be to migrate everyone over to the "newinstance" scheme.
> 
> However, it is increasingly clear that that is not happening; neither
> the distros nor udev support this by default at this point.

Well maybe thats because the legacy mode works perfectly well for most
purposes and does what they want. The "non-legacy" mode is really not
"non-legacy" its "special case extra funkiness".

With my tty hat on I'd prefer to keep it indefinitely if need be. It's
hardly a maintainability issue or a hot problem. We've got much bigger
turds to juggle than that.

I don't see why we need an agendum to force the users into making changes
that really don't matter. I mean we still support BSD ptys 8)

Alan

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

[H. Peter Anvin]

The problem is that the lack of migration at the root causes real problems for the people who need the extra funkiness, and unlike BSD ttys it's not an application-level change at all.

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

>On Sat, 07 Apr 2012 11:36:26 -0700
>"H. Peter Anvin" <hpa@zytor.com> wrote:
>
>> Currently, devpts supports a legacy mode where only one instance
>exists.
>>  For backwards compatibility, this is also the default mode, but the
>> right thing should be to migrate everyone over to the "newinstance"
>scheme.
>> 
>> However, it is increasingly clear that that is not happening; neither
>> the distros nor udev support this by default at this point.
>
>Well maybe thats because the legacy mode works perfectly well for most
>purposes and does what they want. The "non-legacy" mode is really not
>"non-legacy" its "special case extra funkiness".
>
>With my tty hat on I'd prefer to keep it indefinitely if need be. It's
>hardly a maintainability issue or a hot problem. We've got much bigger
>turds to juggle than that.
>
>I don't see why we need an agendum to force the users into making
>changes
>that really don't matter. I mean we still support BSD ptys 8)
>
>Alan

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

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

[Ted Ts'o]

On Sat, Apr 07, 2012 at 01:02:33PM -0700, H. Peter Anvin wrote:
> The problem is that the lack of migration at the root causes real
> problems for the people who need the extra funkiness, and unlike BSD
> ttys it's not an application-level change at all.

Could you explain what the issues are?  I haven't been following
devpts all that carefully.

Thanks,

						- Ted

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

[H. Peter Anvin]

On 04/07/2012 02:27 PM, Ted Ts'o wrote:
> On Sat, Apr 07, 2012 at 01:02:33PM -0700, H. Peter Anvin wrote:
>> The problem is that the lack of migration at the root causes real
>> problems for the people who need the extra funkiness, and unlike BSD
>> ttys it's not an application-level change at all.
> 
> Could you explain what the issues are?  I haven't been following
> devpts all that carefully.
> 

The issue is that to make the "ptys are private to an instance of the
devpts filesystem", /dev/ptmx has to live inside the /dev/pts
filesystem.  This was traditionally not the case.  To avoid breaking
everything all at once, we have a legacy mode which supports the "all
devpts instances are the same" (effectively bind mounts) and which
support a /dev/ptmx outside /dev/pts.

The problem is that anyone who wants to take advantage of the new
functionality has to make sure *all* instances of devpts work with the
new protocol.  This means modifying your distro to:

1. Add "newinstance" and "ptmxmode" to /etc/fstab [easy]
2. Make /dev/ptmx a symlink to /dev/pts/ptmx.

2 would be easy if it wasn't for udev, which makes it very hard.  It is
not reasonable for udev to support both modes, so the *only* mode that
is reasonable for it to support is the new mode.  However, it is
increasingly obvious that if we don't force it, this will never happen.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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

[Kay Sievers]

On Sun, Apr 8, 2012 at 00:03, H. Peter Anvin <hpa@zytor.com> wrote:
> On 04/07/2012 02:27 PM, Ted Ts'o wrote:
>> On Sat, Apr 07, 2012 at 01:02:33PM -0700, H. Peter Anvin wrote:
>>> The problem is that the lack of migration at the root causes real
>>> problems for the people who need the extra funkiness, and unlike BSD
>>> ttys it's not an application-level change at all.
>>
>> Could you explain what the issues are?  I haven't been following
>> devpts all that carefully.
>>
>
> The issue is that to make the "ptys are private to an instance of the
> devpts filesystem", /dev/ptmx has to live inside the /dev/pts
> filesystem.  This was traditionally not the case.  To avoid breaking
> everything all at once, we have a legacy mode which supports the "all
> devpts instances are the same" (effectively bind mounts) and which
> support a /dev/ptmx outside /dev/pts.
>
> The problem is that anyone who wants to take advantage of the new
> functionality has to make sure *all* instances of devpts work with the
> new protocol.  This means modifying your distro to:
>
> 1. Add "newinstance" and "ptmxmode" to /etc/fstab [easy]
> 2. Make /dev/ptmx a symlink to /dev/pts/ptmx.
>
> 2 would be easy if it wasn't for udev, which makes it very hard.  It is
> not reasonable for udev to support both modes, so the *only* mode that
> is reasonable for it to support is the new mode.  However, it is
> increasingly obvious that if we don't force it, this will never happen.

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.

Kay

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

[H. Peter Anvin]

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.

Greg, do you have any insights in what would have to be necessary
mechanics to make this.

	-hpa

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

[Kay Sievers]

On Sun, Apr 8, 2012 at 20:00, H. Peter Anvin <hpa@zytor.com> 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

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@zytor.com> 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

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

[H. Peter Anvin]

On 04/11/2012 04:53 PM, Greg Kroah-Hartman wrote:
> 
> 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?
> 

Drop the newinstance mount option on the floor; keep recognizing the
ptmxmode mount option but change the default.

	-hpa

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

[Greg Kroah-Hartman]

On Wed, Apr 11, 2012 at 04:55:41PM -0700, H. Peter Anvin wrote:
> On 04/11/2012 04:53 PM, Greg Kroah-Hartman wrote:
> > 
> > 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?
> > 
> 
> Drop the newinstance mount option on the floor; keep recognizing the
> ptmxmode mount option but change the default.

Wait, change the default to what?

I think this is going to require a lot of testing :)

greg k-h

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

[Kay Sievers]

On Thu, Apr 12, 2012 at 02:30, Greg Kroah-Hartman
<gregkh@linux-foundation.org> wrote:
> On Wed, Apr 11, 2012 at 04:55:41PM -0700, H. Peter Anvin wrote:
>> On 04/11/2012 04:53 PM, Greg Kroah-Hartman wrote:
>> >
>> > 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?
>> >
>>
>> Drop the newinstance mount option on the floor; keep recognizing the
>> ptmxmode mount option but change the default.
>
> Wait, change the default to what?

Of the devpts fs mount option. The 'newinstance' one, which should not
have existed in the first place.

> I think this is going to require a lot of testing :)

In the example patch I posted and which I ran here, I just removed the
entire option. This was just to show that userspace does not want to
be taught dirty tricks that need updating of early-boot tools. All
such pretty self-contained stuff should be in the kernel itself.
Userspace wants to be dumb here, and that worked fine so far with that
patch. :)

Kay

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

[Greg Kroah-Hartman]

On Thu, Apr 12, 2012 at 02:38:29AM +0200, Kay Sievers wrote:
> On Thu, Apr 12, 2012 at 02:30, Greg Kroah-Hartman
> <gregkh@linux-foundation.org> wrote:
> > On Wed, Apr 11, 2012 at 04:55:41PM -0700, H. Peter Anvin wrote:
> >> On 04/11/2012 04:53 PM, Greg Kroah-Hartman wrote:
> >> >
> >> > 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?
> >> >
> >>
> >> Drop the newinstance mount option on the floor; keep recognizing the
> >> ptmxmode mount option but change the default.
> >
> > Wait, change the default to what?
> 
> Of the devpts fs mount option. The 'newinstance' one, which should not
> have existed in the first place.
> 
> > I think this is going to require a lot of testing :)
> 
> In the example patch I posted and which I ran here, I just removed the
> entire option. This was just to show that userspace does not want to
> be taught dirty tricks that need updating of early-boot tools. All
> such pretty self-contained stuff should be in the kernel itself.
> Userspace wants to be dumb here, and that worked fine so far with that
> patch. :)

I missed your patch, sorry, am catching up on the email thread now...

greg k-h

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

[Al Viro]

On Sun, Apr 08, 2012 at 09:16:22PM +0200, Kay Sievers wrote:

> 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

You do realize that there are people with _static_ /dev out there, don't
you?  As well as those of us who are not using your latest and greatest
udev and not enabling devtmpfs at all.  Not all world is Fedora...

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

[H. Peter Anvin]

Just replace /dev/ptmx with a pts/ptmx symlink... something that works already.

Al Viro <viro@ZenIV.linux.org.uk> wrote:

>On Sun, Apr 08, 2012 at 09:16:22PM +0200, Kay Sievers wrote:
>
>> 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
>
>You do realize that there are people with _static_ /dev out there,
>don't
>you?  As well as those of us who are not using your latest and greatest
>udev and not enabling devtmpfs at all.  Not all world is Fedora...

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

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

[Al Viro]

On Wed, Apr 11, 2012 at 06:56:10PM -0700, H. Peter Anvin wrote:
> Just replace /dev/ptmx with a pts/ptmx symlink... something that works already.

It does *not* work for static setups - try to boot stock 3.3 on the root
fs with such a symlink and you've got a dangling symlink.  Have fun
trying to bisect something with repeated jumps back and forth across the
point where such change goes in...

It will also do no good on setups like e.g. debian/stable, with stock
udev - you need to edit /lib/udev/rules.d/50-udev-default.rules to get
that link created, with quite a bit of interesting kludgery to avoid the
same kind of crap (i.e. setup breaking when you boot an older kernel).

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

[H. Peter Anvin]

The symlink support is at least 3 years old, probably more.

Al Viro <viro@ZenIV.linux.org.uk> wrote:

>On Wed, Apr 11, 2012 at 06:56:10PM -0700, H. Peter Anvin wrote:
>> Just replace /dev/ptmx with a pts/ptmx symlink... something that
>works already.
>
>It does *not* work for static setups - try to boot stock 3.3 on the
>root
>fs with such a symlink and you've got a dangling symlink.  Have fun
>trying to bisect something with repeated jumps back and forth across
>the
>point where such change goes in...
>
>It will also do no good on setups like e.g. debian/stable, with stock
>udev - you need to edit /lib/udev/rules.d/50-udev-default.rules to get
>that link created, with quite a bit of interesting kludgery to avoid
>the
>same kind of crap (i.e. setup breaking when you boot an older kernel).

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

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

[Al Viro]

On Wed, Apr 11, 2012 at 07:48:44PM -0700, H. Peter Anvin wrote:
> The symlink support is at least 3 years old, probably more.

DEVPTS_MULTIPLE_INSTANCES wasn't anywhere near mandatory all that time...
Kernel upgrade procedure that starts with "build the old kernel with
that option enabled, boot it, replace /dev/ptmx with a symlink, then
never try to boot earlier kernel images.  Now you can safely upgrade
to current kernel" is the recipe for massive self-LARTs (and resulting
pitchfork crowds).

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

[H. Peter Anvin]

On 04/11/2012 08:04 PM, Al Viro wrote:
> On Wed, Apr 11, 2012 at 07:48:44PM -0700, H. Peter Anvin wrote:
>> The symlink support is at least 3 years old, probably more.
> 
> DEVPTS_MULTIPLE_INSTANCES wasn't anywhere near mandatory all that time...
> Kernel upgrade procedure that starts with "build the old kernel with
> that option enabled, boot it, replace /dev/ptmx with a symlink, then
> never try to boot earlier kernel images.  Now you can safely upgrade
> to current kernel" is the recipe for massive self-LARTs (and resulting
> pitchfork crowds).

Sounds like the first thing we need to do is to remove the
CONFIG_DEVPTS_MULTIPLE_INSTANCES=n code.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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

[Kay Sievers]

On Thu, Apr 12, 2012 at 03:08, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Sun, Apr 08, 2012 at 09:16:22PM +0200, Kay Sievers wrote:
>
>> 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
>
> You do realize that there are people with _static_ /dev out there, don't
> you?  As well as those of us who are not using your latest and greatest
> udev and not enabling devtmpfs at all.  Not all world is Fedora...

Yeah, and? The dev_t still works from the static /dev/ like it didi 10
years ago. All good.

Not all breaks when I talk about it. :)

Kay

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

[Al Viro]

On Thu, Apr 12, 2012 at 04:27:55AM +0200, Kay Sievers wrote:
> On Thu, Apr 12, 2012 at 03:08, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > On Sun, Apr 08, 2012 at 09:16:22PM +0200, Kay Sievers wrote:
> >
> >> 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
> >
> > You do realize that there are people with _static_ /dev out there, don't
> > you? ??As well as those of us who are not using your latest and greatest
> > udev and not enabling devtmpfs at all. ??Not all world is Fedora...
> 
> Yeah, and? The dev_t still works from the static /dev/ like it didi 10
> years ago. All good.

Only if you move that cdev to fs/devpts/inode.c instead of removing it,
at which point you get the interesting problems back on other setups...

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

[Kay Sievers]

On Thu, Apr 12, 2012 at 04:45, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Thu, Apr 12, 2012 at 04:27:55AM +0200, Kay Sievers wrote:
>> On Thu, Apr 12, 2012 at 03:08, Al Viro <viro@zeniv.linux.org.uk> wrote:
>> > On Sun, Apr 08, 2012 at 09:16:22PM +0200, Kay Sievers wrote:
>> >
>> >> 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
>> >
>> > You do realize that there are people with _static_ /dev out there, don't
>> > you? ??As well as those of us who are not using your latest and greatest
>> > udev and not enabling devtmpfs at all. ??Not all world is Fedora...
>>
>> Yeah, and? The dev_t still works from the static /dev/ like it didi 10
>> years ago. All good.
>
> Only if you move that cdev to fs/devpts/inode.c instead of removing it,
> at which point you get the interesting problems back on other setups...

fs/devpts/inode.c uses the very _same_ registered cdev, nobody wants
or can remove it.

Kay

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

[H. Peter Anvin]

On 04/11/2012 07:27 PM, Kay Sievers wrote:
> 
> Yeah, and? The dev_t still works from the static /dev/ like it didi 10
> years ago. All good.
> 

That *is* the legacy mode which we'd like to get rid of.

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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

[Kay Sievers]

On Thu, Apr 12, 2012 at 04:53, H. Peter Anvin <hpa@zytor.com> wrote:
> On 04/11/2012 07:27 PM, Kay Sievers wrote:
>>
>> Yeah, and? The dev_t still works from the static /dev/ like it didi 10
>> years ago. All good.
>
> That *is* the legacy mode which we'd like to get rid of.

Not sure if that will work. We might need to keep that for a while.
And static /dev and old udevs and mdev and whatever will just work as
they do today.

But the non-legacy mode compile option can be, as far as I see, still
be made working without requiring mount options and without requiring
any userspace changes.

What we get rid of then is not the legacy support, but the need to
manually switch userspace over. It's just a compile option then, and
people with static or ancient stuff do not switch, and everybody else
gets switched and will not notice.

Kay

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

[Alan Cox]

> 2 would be easy if it wasn't for udev, which makes it very hard.  It is
> not reasonable for udev to support both modes, so the *only* mode that
> is reasonable for it to support is the new mode.  However, it is
> increasingly obvious that if we don't force it, this will never happen.

If enough people care about it then udev will get fixed. Using the kernel
as a large hammer to try and force one worldview onto people who couldn't
give a flying.. isn't the right answer here.

Get the distros to switch mode by asking them and/or by sending them
changes for new releases.

Alan

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

[H. Peter Anvin]

Even "doing it manually" gets hard because udev gets in the way.

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

>On Sat, 07 Apr 2012 11:36:26 -0700
>"H. Peter Anvin" <hpa@zytor.com> wrote:
>
>> Currently, devpts supports a legacy mode where only one instance
>exists.
>>  For backwards compatibility, this is also the default mode, but the
>> right thing should be to migrate everyone over to the "newinstance"
>scheme.
>> 
>> However, it is increasingly clear that that is not happening; neither
>> the distros nor udev support this by default at this point.
>
>Well maybe thats because the legacy mode works perfectly well for most
>purposes and does what they want. The "non-legacy" mode is really not
>"non-legacy" its "special case extra funkiness".
>
>With my tty hat on I'd prefer to keep it indefinitely if need be. It's
>hardly a maintainability issue or a hot problem. We've got much bigger
>turds to juggle than that.
>
>I don't see why we need an agendum to force the users into making
>changes
>that really don't matter. I mean we still support BSD ptys 8)
>
>Alan

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

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

[Konstantin Khlebnikov]

H. Peter Anvin wrote:
> Currently, devpts supports a legacy mode where only one instance exists.
>   For backwards compatibility, this is also the default mode, but the
> right thing should be to migrate everyone over to the "newinstance" scheme.
>
> However, it is increasingly clear that that is not happening; neither
> the distros nor udev support this by default at this point.
>
> I think it might be time we set a sunset date for the legacy mode,
> probably around kernel 3.9 at this point.
>
> The big change is that /dev/ptmx instead of being a device node should
> be a symlink to /dev/pts/ptmx, which is then either chmodded to the
> proper permissions, or given proper permissions via the ptmxmode mount
> options to devpts.  The latter is probably preferable from a technical
> point of view since it doesn't create a "gap".
>
> As such, I would like to suggest the following:
>
> 1. For 3.5, add this to feature-removal.txt.
> 2. For 3.6, remove CONFIG_DEVPTS_MULTIPLE_INSTANCES as a configuration
>     option, and printk a warning if devpts is mounted without the
>     "newinstance" option.
> 3. For 3.9 remove the legacy support including support for a ptmx node
>     outside the devpts filesystem.
>
> 	-hpa
>

I think we should give the way to test compatibility as early as possible, so:
2'. For 3.6 add CONFIG_DEVPTS_LEGACY_INSTANCE =y by default, if it =n:
     always create new instance (ignore "newinstance") and remove "ptmx" from sysfs.

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

[Alan Cox]

> > As such, I would like to suggest the following:
> >
> > 1. For 3.5, add this to feature-removal.txt.
> > 2. For 3.6, remove CONFIG_DEVPTS_MULTIPLE_INSTANCES as a configuration
> >     option, and printk a warning if devpts is mounted without the
> >     "newinstance" option.
> > 3. For 3.9 remove the legacy support including support for a ptmx node
> >     outside the devpts filesystem.

Ok I'm putting my tty maintainers hat on at this point because nobody
seems to be listening

I'm NAKking this change, I'm NAKking the feature-removal change.

If you want this to change convince the distributions there is a point in
supporting it. This is the *wrong* forum to force a cornercase feature
onto a bazillion users, and the wrong way to strongarm maintainers of the
relevant user space.

If udev has a problem handling it nicely because of the way the link is
generated then *fix that problem* so udev automatically gets both cases
right. If need be we can add more messages to udev to tell it what is
expected and what devtmpfs should produce.

Alan

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

[H. Peter Anvin]

On 04/08/2012 03:18 PM, Alan Cox wrote:
> 
> Ok I'm putting my tty maintainers hat on at this point because nobody
> seems to be listening
> 
> I'm NAKking this change, I'm NAKking the feature-removal change.
> 
> If you want this to change convince the distributions there is a point in
> supporting it. This is the *wrong* forum to force a cornercase feature
> onto a bazillion users, and the wrong way to strongarm maintainers of the
> relevant user space.
> 
> If udev has a problem handling it nicely because of the way the link is
> generated then *fix that problem* so udev automatically gets both cases
> right. If need be we can add more messages to udev to tell it what is
> expected and what devtmpfs should produce.
> 

What if it turns out we can make udev/devtmpfs make this happen
transparently (which it sounds like it might be possible)?  Would you be
okay with removing the "implicit bind mount" property of the current
devpts then?

	-hpa


-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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

[Alan Cox]

> What if it turns out we can make udev/devtmpfs make this happen
> transparently (which it sounds like it might be possible)?  Would you be
> okay with removing the "implicit bind mount" property of the current
> devpts then?

Once we get to the point where it "just works" I'm quite happy for that
to happen unless it turns out there's any large code size/performance
hits in having the feature always on. I don't see any.

Alan

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

[H. Peter Anvin]

On 04/08/2012 03:46 PM, Alan Cox wrote:
>> What if it turns out we can make udev/devtmpfs make this happen
>> transparently (which it sounds like it might be possible)?  Would you be
>> okay with removing the "implicit bind mount" property of the current
>> devpts then?
> 
> Once we get to the point where it "just works" I'm quite happy for that
> to happen unless it turns out there's any large code size/performance
> hits in having the feature always on. I don't see any.
> 

No, it's actually the other way around... it lets us take some pretty
nice shortcuts.

	-hpa

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

[Theodore Tso]

On Apr 8, 2012, at 6:45 PM, H. Peter Anvin wrote:

> On 04/08/2012 03:46 PM, Alan Cox wrote:
>>> What if it turns out we can make udev/devtmpfs make this happen
>>> transparently (which it sounds like it might be possible)?  Would you be
>>> okay with removing the "implicit bind mount" property of the current
>>> devpts then?
>> 
>> Once we get to the point where it "just works" I'm quite happy for that
>> to happen unless it turns out there's any large code size/performance
>> hits in having the feature always on. I don't see any.
>> 
> 
> No, it's actually the other way around... it lets us take some pretty
> nice shortcuts.

If it requires making changes to udev, can we place make sure have
a decent amount of time before we remove code from the kernel? 
I really hate it when people break userspace for the convenience
of kernel programmers.   As I recall Linus had something to say
about that….

-- Ted

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

[Kay Sievers]

On Sun, 2012-04-08 at 23:15 -0400, Theodore Tso wrote:
> On Apr 8, 2012, at 6:45 PM, H. Peter Anvin wrote:
> 
> > On 04/08/2012 03:46 PM, Alan Cox wrote:
> >>> What if it turns out we can make udev/devtmpfs make this happen
> >>> transparently (which it sounds like it might be possible)?  Would you be
> >>> okay with removing the "implicit bind mount" property of the current
> >>> devpts then?
> >> 
> >> Once we get to the point where it "just works" I'm quite happy for that
> >> to happen unless it turns out there's any large code size/performance
> >> hits in having the feature always on. I don't see any.
> >> 
> > 
> > No, it's actually the other way around... it lets us take some pretty
> > nice shortcuts.
> 
> If it requires making changes to udev, can we place make sure have
> a decent amount of time before we remove code from the kernel? 
> I really hate it when people break userspace for the convenience
> of kernel programmers.   As I recall Linus had something to say
> about that….

As mentioned earlier, udev is not involved at all here. It's all in the
kernel these days; all device nodes are created by the kernel and not by
udev.

The one that is in the way here is created by kernel code, and udev will
never gain options or support instructions to delete kernel-created
nodes. We refuse to teach udev stupid tricks to work around the kernel's
idea of new features and options.

The entire idea of legacy vs. non-legacy for devpts is kind of broken to
begin with. Requiring to delete kernel-created device nodes and
replacing them with symlinks, like mentioned in the devpts
documentation, should never be a job for userspace; it needs to be done
properly inside the kernel.

Today, userspace should not be required to fiddle around with such
stuff, it just mounts the filesystem like it always did, and nothing
else. I does not want to know about any new options in such category,
which can work on specific kernels only, and will cause too much trouble
to support in the end.

The following patch is just to clean up the confusion about userspace
and the unfortunate idea of legacy vs. non-legacy mount options. It is
nowhere ready to merge, but it should make is pretty clear, that
userspace should be left alone here, and it's a job for the kernel only.

Cheers,
Kay

# ls -l /dev
crw------- 1 root root     10,   1 Apr  9 14:21 psaux
lrwxrwxrwx 1 root root           8 Apr  9 14:20 ptmx -> pts/ptmx
drwxr-xr-x 2 root root           0 Apr  9 14:21 pts
crw-rw-rw- 1 root root      1,   8 Apr  9 14:21 random

# ls -l /dev/pts
total 0
crw--w---- 1 root tty 136, 0 Apr  9 14:22 0
crw--w---- 1 kay  tty 136, 1 Apr  9 14:22 1
crw-rw-rw- 1 root tty   5, 2 Apr  9 14:22 ptmx

---
 drivers/base/devtmpfs.c |   60 ++++++++++++++++++++++++-
 drivers/tty/Kconfig     |   11 ----
 drivers/tty/pty.c       |    3 -
 fs/devpts/inode.c       |  112 +++++++-----------------------------------------
 include/linux/device.h  |    2 
 5 files changed, 76 insertions(+), 112 deletions(-)

--- a/drivers/base/devtmpfs.c
+++ b/drivers/base/devtmpfs.c
@@ -40,6 +40,7 @@ static struct req {
 	struct completion done;
 	int err;
 	const char *name;
+	const char *target;
 	umode_t mode;	/* 0 => delete */
 	struct device *dev;
 } *requests;
@@ -84,7 +85,7 @@ int devtmpfs_create_node(struct device *
 	if (!thread)
 		return 0;
 
-	req.mode = 0;
+	memset(&req, 0, sizeof(struct req));
 	req.name = device_get_devnode(dev, &req.mode, &tmp);
 	if (!req.name)
 		return -ENOMEM;
@@ -113,6 +114,31 @@ int devtmpfs_create_node(struct device *
 	return req.err;
 }
 
+int devtmpfs_create_link(const char *name, const char *target)
+{
+	struct req req;
+
+	if (!thread)
+		return 0;
+
+	memset(&req, 0, sizeof(struct req));
+	req.mode = 0666;
+	req.name = name;
+	req.target = target;
+
+	init_completion(&req.done);
+
+	spin_lock(&req_lock);
+	req.next = requests;
+	requests = &req;
+	spin_unlock(&req_lock);
+
+	wake_up_process(thread);
+	wait_for_completion(&req.done);
+
+	return req.err;
+}
+
 int devtmpfs_delete_node(struct device *dev)
 {
 	const char *tmp = NULL;
@@ -121,11 +147,11 @@ int devtmpfs_delete_node(struct device *
 	if (!thread)
 		return 0;
 
+	memset(&req, 0, sizeof(struct req));
 	req.name = device_get_devnode(dev, NULL, &tmp);
 	if (!req.name)
 		return -ENOMEM;
 
-	req.mode = 0;
 	req.dev = dev;
 
 	init_completion(&req.done);
@@ -225,6 +251,28 @@ static int handle_create(const char *nod
 	return err;
 }
 
+static int handle_create_link(const char *name, const char *target)
+{
+	struct dentry *dentry;
+	struct path path;
+	int err;
+
+	dentry = kern_path_create(AT_FDCWD, name, &path, 0);
+	if (dentry == ERR_PTR(-ENOENT)) {
+		create_path(name);
+		dentry = kern_path_create(AT_FDCWD, name, &path, 0);
+	}
+	if (IS_ERR(dentry))
+		return PTR_ERR(dentry);
+
+	err = vfs_symlink(path.dentry->d_inode, dentry, target);
+	dput(dentry);
+
+	mutex_unlock(&path.dentry->d_inode->i_mutex);
+	path_put(&path);
+	return err;
+}
+
 static int dev_rmdir(const char *name)
 {
 	struct nameidata nd;
@@ -378,8 +426,11 @@ int devtmpfs_mount(const char *mntdir)
 
 static DECLARE_COMPLETION(setup_done);
 
-static int handle(const char *name, umode_t mode, struct device *dev)
+static int handle(const char *name, umode_t mode,
+		  struct device *dev, const char *target)
 {
+	if (target)
+		return handle_create_link(name, target);
 	if (mode)
 		return handle_create(name, mode, dev);
 	else
@@ -407,7 +458,8 @@ static int devtmpfsd(void *p)
 			spin_unlock(&req_lock);
 			while (req) {
 				struct req *next = req->next;
-				req->err = handle(req->name, req->mode, req->dev);
+				req->err = handle(req->name, req->mode,
+						  req->dev, req->target);
 				complete(&req->done);
 				req = next;
 			}
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -109,17 +109,6 @@ config UNIX98_PTYS
 	  All modern Linux systems use the Unix98 ptys.  Say Y unless
 	  you're on an embedded system and want to conserve memory.
 
-config DEVPTS_MULTIPLE_INSTANCES
-	bool "Support multiple instances of devpts"
-	depends on UNIX98_PTYS
-	default n
-	---help---
-	  Enable support for multiple instances of devpts filesystem.
-	  If you want to have isolated PTY namespaces (eg: in containers),
-	  say Y here.  Otherwise, say N. If enabled, each mount of devpts
-	  filesystem with the '-o newinstance' option will create an
-	  independent PTY namespace.
-
 config LEGACY_PTYS
 	bool "Legacy (BSD) PTY support"
 	default y
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -706,7 +706,7 @@ static void __init unix98_pty_init(void)
 	if (tty_register_driver(pts_driver))
 		panic("Couldn't register Unix98 pts driver");
 
-	/* Now create the /dev/ptmx special device */
+	/* Hook up the ptmx cdev which lives inside the devpts filesystem */
 	tty_default_fops(&ptmx_fops);
 	ptmx_fops.open = ptmx_open;
 
@@ -714,7 +714,6 @@ static void __init unix98_pty_init(void)
 	if (cdev_add(&ptmx_cdev, MKDEV(TTYAUX_MAJOR, 2), 1) ||
 	    register_chrdev_region(MKDEV(TTYAUX_MAJOR, 2), 1, "/dev/ptmx") < 0)
 		panic("Couldn't register /dev/ptmx driver\n");
-	device_create(tty_class, NULL, MKDEV(TTYAUX_MAJOR, 2), NULL, "ptmx");
 }
 
 #else
--- a/fs/devpts/inode.c
+++ b/fs/devpts/inode.c
@@ -26,15 +26,9 @@
 #include <linux/fsnotify.h>
 #include <linux/seq_file.h>
 
-#define DEVPTS_DEFAULT_MODE 0600
-/*
- * ptmx is a new node in /dev/pts and will be unused in legacy (single-
- * instance) mode. To prevent surprises in user space, set permissions of
- * ptmx to 0. Use 'chmod' or remount with '-o ptmxmode' to set meaningful
- * permissions.
- */
-#define DEVPTS_DEFAULT_PTMX_MODE 0000
-#define PTMX_MINOR	2
+#define DEVPTS_DEFAULT_MODE		0600
+#define DEVPTS_DEFAULT_PTMX_MODE	0666
+#define PTMX_MINOR			2
 
 /*
  * sysctl support for setting limits on the number of Unix98 ptys allocated.
@@ -102,24 +96,19 @@ struct pts_mount_opts {
 	gid_t   gid;
 	umode_t mode;
 	umode_t ptmxmode;
-	int newinstance;
 	int max;
 };
 
 enum {
-	Opt_uid, Opt_gid, Opt_mode, Opt_ptmxmode, Opt_newinstance,  Opt_max,
-	Opt_err
+	Opt_uid, Opt_gid, Opt_mode, Opt_ptmxmode, Opt_max, Opt_err
 };
 
 static const match_table_t tokens = {
 	{Opt_uid, "uid=%u"},
 	{Opt_gid, "gid=%u"},
 	{Opt_mode, "mode=%o"},
-#ifdef CONFIG_DEVPTS_MULTIPLE_INSTANCES
 	{Opt_ptmxmode, "ptmxmode=%o"},
-	{Opt_newinstance, "newinstance"},
 	{Opt_max, "max=%d"},
-#endif
 	{Opt_err, NULL}
 };
 
@@ -136,10 +125,8 @@ static inline struct pts_fs_info *DEVPTS
 
 static inline struct super_block *pts_sb_from_inode(struct inode *inode)
 {
-#ifdef CONFIG_DEVPTS_MULTIPLE_INSTANCES
 	if (inode->i_sb->s_magic == DEVPTS_SUPER_MAGIC)
 		return inode->i_sb;
-#endif
 	return devpts_mnt->mnt_sb;
 }
 
@@ -149,9 +136,7 @@ static inline struct super_block *pts_sb
 /*
  * parse_mount_options():
  * 	Set @opts to mount options specified in @data. If an option is not
- * 	specified in @data, set it to its default value. The exception is
- * 	'newinstance' option which can only be set/cleared on a mount (i.e.
- * 	cannot be changed during remount).
+ * 	specified in @data, set it to its default value.\
  *
  * Note: @data may be NULL (in which case all options are set to default).
  */
@@ -167,10 +152,6 @@ static int parse_mount_options(char *dat
 	opts->ptmxmode = DEVPTS_DEFAULT_PTMX_MODE;
 	opts->max     = NR_UNIX98_PTY_MAX;
 
-	/* newinstance makes sense only on initial mount */
-	if (op == PARSE_MOUNT)
-		opts->newinstance = 0;
-
 	while ((p = strsep(&data, ",")) != NULL) {
 		substring_t args[MAX_OPT_ARGS];
 		int token;
@@ -198,24 +179,17 @@ static int parse_mount_options(char *dat
 				return -EINVAL;
 			opts->mode = option & S_IALLUGO;
 			break;
-#ifdef CONFIG_DEVPTS_MULTIPLE_INSTANCES
 		case Opt_ptmxmode:
 			if (match_octal(&args[0], &option))
 				return -EINVAL;
 			opts->ptmxmode = option & S_IALLUGO;
 			break;
-		case Opt_newinstance:
-			/* newinstance makes sense only on initial mount */
-			if (op == PARSE_MOUNT)
-				opts->newinstance = 1;
-			break;
 		case Opt_max:
 			if (match_int(&args[0], &option) ||
 			    option < 0 || option > NR_UNIX98_PTY_MAX)
 				return -EINVAL;
 			opts->max = option;
 			break;
-#endif
 		default:
 			printk(KERN_ERR "devpts: called with bogus options\n");
 			return -EINVAL;
@@ -225,7 +199,6 @@ static int parse_mount_options(char *dat
 	return 0;
 }
 
-#ifdef CONFIG_DEVPTS_MULTIPLE_INSTANCES
 static int mknod_ptmx(struct super_block *sb)
 {
 	int mode;
@@ -260,6 +233,8 @@ static int mknod_ptmx(struct super_block
 		goto out;
 	}
 
+	if (opts->setgid)
+		inode->i_gid = opts->gid;
 	inode->i_ino = 2;
 	inode->i_mtime = inode->i_atime = inode->i_ctime = CURRENT_TIME;
 
@@ -283,12 +258,6 @@ static void update_ptmx_mode(struct pts_
 		inode->i_mode = S_IFCHR|fsi->mount_opts.ptmxmode;
 	}
 }
-#else
-static inline void update_ptmx_mode(struct pts_fs_info *fsi)
-{
-       return;
-}
-#endif
 
 static int devpts_remount(struct super_block *sb, int *flags, char *data)
 {
@@ -319,11 +288,9 @@ static int devpts_show_options(struct se
 	if (opts->setgid)
 		seq_printf(seq, ",gid=%u", opts->gid);
 	seq_printf(seq, ",mode=%03o", opts->mode);
-#ifdef CONFIG_DEVPTS_MULTIPLE_INSTANCES
 	seq_printf(seq, ",ptmxmode=%03o", opts->ptmxmode);
 	if (opts->max < NR_UNIX98_PTY_MAX)
 		seq_printf(seq, ",max=%d", opts->max);
-#endif
 
 	return 0;
 }
@@ -384,43 +351,8 @@ fail:
 	return -ENOMEM;
 }
 
-#ifdef CONFIG_DEVPTS_MULTIPLE_INSTANCES
-static int compare_init_pts_sb(struct super_block *s, void *p)
-{
-	if (devpts_mnt)
-		return devpts_mnt->mnt_sb == s;
-	return 0;
-}
-
-/*
- * devpts_mount()
- *
- *     If the '-o newinstance' mount option was specified, mount a new
- *     (private) instance of devpts.  PTYs created in this instance are
- *     independent of the PTYs in other devpts instances.
- *
- *     If the '-o newinstance' option was not specified, mount/remount the
- *     initial kernel mount of devpts.  This type of mount gives the
- *     legacy, single-instance semantics.
- *
- *     The 'newinstance' option is needed to support multiple namespace
- *     semantics in devpts while preserving backward compatibility of the
- *     current 'single-namespace' semantics. i.e all mounts of devpts
- *     without the 'newinstance' mount option should bind to the initial
- *     kernel mount, like mount_single().
- *
- *     Mounts with 'newinstance' option create a new, private namespace.
- *
- *     NOTE:
- *
- *     For single-mount semantics, devpts cannot use mount_single(),
- *     because mount_single()/sget() find and use the super-block from
- *     the most recent mount of devpts. But that recent mount may be a
- *     'newinstance' mount and mount_single() would pick the newinstance
- *     super-block instead of the initial super-block.
- */
 static struct dentry *devpts_mount(struct file_system_type *fs_type,
-	int flags, const char *dev_name, void *data)
+				   int flags, const char *dev_name, void *data)
 {
 	int error;
 	struct pts_mount_opts opts;
@@ -430,10 +362,7 @@ static struct dentry *devpts_mount(struc
 	if (error)
 		return ERR_PTR(error);
 
-	if (opts.newinstance)
-		s = sget(fs_type, NULL, set_anon_super, NULL);
-	else
-		s = sget(fs_type, compare_init_pts_sb, set_anon_super, NULL);
+	s = sget(fs_type, NULL, set_anon_super, NULL);
 
 	if (IS_ERR(s))
 		return ERR_CAST(s);
@@ -459,18 +388,6 @@ out_undo_sget:
 	return ERR_PTR(error);
 }
 
-#else
-/*
- * This supports only the legacy single-instance semantics (no
- * multiple-instance semantics)
- */
-static struct dentry *devpts_mount(struct file_system_type *fs_type, int flags,
-		const char *dev_name, void *data)
-{
-	return mount_single(fs_type, flags, data, devpts_fill_super);
-}
-#endif
-
 static void devpts_kill_sb(struct super_block *sb)
 {
 	struct pts_fs_info *fsi = DEVPTS_SB(sb);
@@ -502,8 +419,7 @@ retry:
 		return -ENOMEM;
 
 	mutex_lock(&allocated_ptys_lock);
-	if (pty_count >= pty_limit -
-			(fsi->mount_opts.newinstance ? pty_reserve : 0)) {
+	if (pty_count >= pty_limit - pty_reserve) {
 		mutex_unlock(&allocated_ptys_lock);
 		return -ENOSPC;
 	}
@@ -629,9 +545,15 @@ void devpts_pty_kill(struct tty_struct *
 
 static int __init init_devpts_fs(void)
 {
-	int err = register_filesystem(&devpts_fs_type);
+	int err;
 	struct ctl_table_header *table;
 
+	err = devtmpfs_create_link("ptmx", "pts/ptmx");
+	if (err)
+		return err;
+
+	err = register_filesystem(&devpts_fs_type);
+
 	if (!err) {
 		table = register_sysctl_table(pty_root_table);
 		devpts_mnt = kern_mount(&devpts_fs_type);
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -858,10 +858,12 @@ extern void put_device(struct device *de
 extern void wait_for_device_probe(void);
 
 #ifdef CONFIG_DEVTMPFS
+extern int devtmpfs_create_link(const char *name, const char *target);
 extern int devtmpfs_create_node(struct device *dev);
 extern int devtmpfs_delete_node(struct device *dev);
 extern int devtmpfs_mount(const char *mntdir);
 #else
+static int devtmpfs_create_link(const char *name, const char *target) { return 0; }
 static inline int devtmpfs_create_node(struct device *dev) { return 0; }
 static inline int devtmpfs_delete_node(struct device *dev) { return 0; }
 static inline int devtmpfs_mount(const char *mountpoint) { return 0; }

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

[Al Viro]

On Mon, Apr 09, 2012 at 02:43:55PM +0200, Kay Sievers wrote:

> As mentioned earlier, udev is not involved at all here. It's all in the
> kernel these days; all device nodes are created by the kernel and not by
> udev.

... on the systems that have devtmpfs enabled.  And no, "runs castrated
udev" is not "all systems out there that might want a new kernel".