lkml.org 
[lkml]   [2016]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Does anyone care about a race free ptsname?
From
Date
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.

\
 
 \ /
  Last update: 2016-04-19 21:41    [W:0.402 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site