This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] getpt: use /dev/pts/ptmx as default ptmx master
- From: Zack Weinberg <zackw at panix dot com>
- To: Christian Brauner <christian dot brauner at canonical dot com>
- Cc: Christian Brauner <christian dot brauner at ubuntu dot com>, ebiederm at xmission dot com, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 15 Mar 2018 10:38:07 -0400
- Subject: Re: [PATCH] getpt: use /dev/pts/ptmx as default ptmx master
- References: <20180315120651.14107-1-christian.brauner@ubuntu.com> <CAKCAbMjcEM-Wev77C6qPH=PmtWtE5C_o94E0O2e6c_oBUvif5A@mail.gmail.com> <20180315141046.GA15486@gmail.com>
On Thu, Mar 15, 2018 at 10:10 AM, Christian Brauner
<christian.brauner@canonical.com> wrote:
> On Thu, Mar 15, 2018 at 10:02:56AM -0400, Zack Weinberg wrote:
>> On Thu, Mar 15, 2018 at 8:06 AM, Christian Brauner
>> <christian.brauner@ubuntu.com> wrote:
>> > For a long time now Linux has placed the ptmx character device directly
>> > under the devpts mount at /dev/pts/ptmx.
>>
>> Exactly which kernel version started doing this?
>
> The article about the patch is here.
> https://lwn.net/Articles/689539/
I'm afraid I don't know how to work out from that article which
_release version_ of the kernel first provided ptmx inside devpts.
However, that's dated 2016 and the oldest kernel that glibc still
supports for runtime use is 3.2, which came out in 2012, so I conclude
we do need the fallback code, at least.
>> > It is time to start switching to using /dev/pts/ptmx and use /dev/ptmx as a
>> > fallback only.
>>
>> Application code is entitled to do open ('/dev/ptmx", O_RDWR) itself
>> rather than calling posix_openpt. It is not OK to break those
>> applications. That was the recommended practice prior to the
>> introduction of posix_openpt, and I am suspicious of posix_openpt not
>> existing on still-reasonable portability targets.
>>
>> Since /dev/ptmx must stick around for the sake of those applications,
>> I am inclined to say that libc's posix_openpt should continue using
>> /dev/ptmx as well, in order to ensure that that configuration
>> continues to be tested. I am also inclined to say that, on new
>> kernels where the devpts filesystem provides the ptmx node, using a
>> bind-mount rather than a symlink for /dev/ptmx is a misconfiguration
>> (and on older kernels, obviously it needs to be an actual device
>> node).
>
> Neither the kernel nor this patch breaks userspace applications. Maybe
> I'm being dense but what argument supports this assumption?
> This patch extends __posix_openpt() to try and open(/dev/pts/ptmx) first
> and if it fails for any reason retry with open(/dev/ptmx).
Sorry, I was unclear.
The scenario I want to avoid is, five to ten years in the future,
someone - perhaps a sloppy container constructor - thinks that
/dev/ptmx can be dropped. This is not OK, even that far ahead,
because it might break applications. In order to prevent that from
happening, I think glibc should continue to use only /dev/ptmx, so
that the breakage will be immediate and obviously the fault of the
sloppy container constructor.
I have no objection to your _kernel_ patch, I just think it's silly to
use a bind-mount for /dev/ptmx when a symlink will work just as well
(in fact, better).
zw