public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Christian Brauner <christian.brauner@canonical.com>
To: Zack Weinberg <zackw@panix.com>
Cc: Christian Brauner <christian.brauner@ubuntu.com>,
	ebiederm@xmission.com, GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH] getpt: use /dev/pts/ptmx as default ptmx master
Date: Thu, 15 Mar 2018 14:10:00 -0000	[thread overview]
Message-ID: <20180315141046.GA15486@gmail.com> (raw)
In-Reply-To: <CAKCAbMjcEM-Wev77C6qPH=PmtWtE5C_o94E0O2e6c_oBUvif5A@mail.gmail.com>

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/

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

Christian

  reply	other threads:[~2018-03-15 14:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-15 12:07 Christian Brauner
2018-03-15 12:08 ` Christian Brauner
2018-03-15 14:03 ` Zack Weinberg
2018-03-15 14:10   ` Christian Brauner [this message]
2018-03-15 14:38     ` Zack Weinberg
2018-03-15 14:49       ` Christian Brauner
     [not found] ` <1521124913.18801.73.camel@pbcl.net>
2018-03-15 14:53   ` Christian Brauner
2018-03-15 20:03 ` Eric W. Biederman
2018-03-15 20:12   ` Christian Brauner
2018-03-15 20:28     ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180315141046.GA15486@gmail.com \
    --to=christian.brauner@canonical.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=ebiederm@xmission.com \
    --cc=libc-alpha@sourceware.org \
    --cc=zackw@panix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).