Linus Torvalds <torva...@linux-foundation.org> writes: > On Thu, Aug 24, 2017 at 1:43 PM, Eric W. Biederman > <ebied...@xmission.com> wrote: >> >> There are just enough weird one off scripts like xen image builder (I >> think that was the nasty test case that broke in debian) that I can't >> imagine ever being able to responsibly remove the path based lookups in >> /dev/ptmx. I do dream of it sometimes. > > Not going to happen.
Which is what I said. > The fact is, /dev/ptmx is the simply the standard location. > /dev/pts/ptmx simply is *not*. The standard is posix_openpt(). That is a syscall on the bsds. Opening something called ptmx at this point is a Linuxism. There are a lot of programs that are going to be calling posix_openpt() simply because /dev/ptmx can not be counted on to exist. > So pretty much every single user that ever uses pty's will use > /dev/ptmx, it's just how it has always worked. > > Trying to change it to anything else is just stupid. There's no > upside, there is only downsides - mainly the "we'll have to support > the standard way anyway, that newfangled way doesn't add anything". Except the new fangled way does add quite a bit. Not everyone who mounts devpts has permission to call mknod. So /dev/ptmx frequently winds up either being a bind mount or a symlink to /dev/pts/ptmx in containers. It is going to take a long time but device nodes like one of those filesystem features thare are very slowly on their way out. > Our "pts" lookup isn't expensive. > > So quite frankly, we should discourage people from using the > non-standard place. It really has no real advantages, and it's simply > not worth it. The "pts" lookup admitted isn't runtime expensive. I could propbably measure a cost but anyone who is creating ptys fast enough to care likely has other issues. The "pts" lookup does have some real maintenance costs as it takes someone with a pretty deep understanding of things to figure out what is going on. I hope things have finally been abstracted well enough, and the code is used heavily enough we don't have to worry about a regression there. I still worry. As for non-standard locations. Anything that isn't /dev/ptmx and /dev/pts/NNN simply won't work for anything isn't very specialized. At which point I don't think there is any reason to skip using the ptmx node on the devpts filesystem as you have already given up compatibility with everything else. But I agree it doesn't look worth it to change glibc to deal with an alternate location for /dev/ptmx. I see a huge point in changing glibc to use the new TIOCGPTPEER ioctl when available as that is really the functionality the glibc internals are after. Eric
