Messages in this thread |  | | From | Linus Torvalds <> | Date | Fri, 25 Aug 2017 18:00:35 -0700 | Subject | Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name |
| |
On Thu, Aug 24, 2017 at 4:37 PM, Christian Brauner <christian.brauner@canonical.com> wrote: > > In fact, /dev/ptmx being a symlink or bind-mount is the *standard* in containers > even for non-user namespaced containers or containers that do not retain > CAP_MKNOD.
Yes.
I think using /dev/pts/ptmx is nice from a kernel standpoint, but I really think that user space should *never* use it.
The distro or container setup can do whatever it wants to made /dev/ptmx then point into the pts directory. Either the traditional device node, the symlink, or the bind mount works fine. But the point is that glibc definitely should *not* point to /dev/pts/ptmx itself, because it's simply not the right path. On lots of distributions that path simply will not work.
And yes, I agree that the user interface to this all is particularly nasty. With TIOCGPTPEER we have a nice way to get the pts file descriptor, but the "normal" way to get to it involves opening a path given by ptsname(), so we en dup in the crazy situation that we can easily open the file without the path, but then we use the fd to get the path (that we didn't need) and then people open it with that path, because the standard sequence to get a pts is
master = getpt() / posix_openpt() / open("/dev/ptmx", O_RDWR | O_NOCTTY); grantpt(master); unlockpt(master); name = ptsname(master); slave = open(name, O_RDWR);
which is kind of silly. And I'm not talking about the three different ways to open the master side. I'm talking about all the rest, which is all just pretty much garbage.
But I guess none of this is really performance-critical.
Linus
|  |