Messages in this thread | | | Subject | Re: Does anyone care about a race free ptsname? | From | "H. Peter Anvin" <> | Date | Tue, 19 Apr 2016 12:16:13 -0700 |
| |
On April 19, 2016 11:44:40 AM PDT, ebiederm@xmission.com wrote: >Linus Torvalds <torvalds@linux-foundation.org> writes: > >> What this does is get rid of the horrible notion of having that >> >> struct inode *ptmx_inode >> >> be the interface between the pty code and devpts. By de-emphasizing >the >> ptmx inode, a lot of things actually get cleaner, and we will have a >much >> saner way forward. > >I will take a look in a minute. Before I do that I want to mention >why I care about /dev/pts/ptmx. > >There is a posix function that is widely used called ptsname. It's >function is to take a master file descriptor and returns the path to >the >slave. > >All we have in the kernel to support ptsname is an ioctl TIOCGPTN that >returns the pty number in the appropriate instance of devpts. > >The only way we have today to query which instance of devpts the pty is >on is through fstat and look st_dev to see if the file is on the >correct >filesystem. This works when /dev/pts/ptmx is used and fails when >/dev/ptmx is used. > >Does anyone else care? > >If no one cares I will stop worrying about it and just get on with >fixing the rest of this mess which there definitely seems to be the >will >to do. > >Eric
We could add another ioctl for that purpose of we need to. Perhaps an ioctl which returns a file descriptor to the slave device?
However, since we are now defining ptmx to explicitly look up pts/ by name it seems like /dev/ptmx -> /dev/pts/# is true by definition. If what you worry about is namespace reshuffling then ptsname() is the wrong interface in the first place since it returns a pathname.
Fwiw, in klibc ptsname() is basically just an sprintf(). -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
| |