Richard> Andreas Jaeger writes:
>> >>>>> Stefan Monnier writes:
>>
>> >>>>> "Andreas" == Andreas Jaeger <aj@suse.de> writes:
>> >> We have to check for the magic because you can have a directory
>> >> /dev/pts but not devpts compiled into your kernel. Therefore we need
>> >> a way to know exactly if devpts is available.
>>
Stefan> Isn't it possible to use a more direct approach where you
Stefan> use the devpts code and if the kernel burps or if the file does not
Stefan> appear under /dev/pts, you revert to the other case ?
>>
>> I've digged a bit at the glibc part. The problematic case [1] is a
>> kernel that has devpts support compiled in but /dev/pts is not
>> mounted.
>>
>> In this case
>> fd = open ("/dev/ptmx", O_RDWR);
>> succeeds - and the return value is just an fd. Checking if that fd
>> really exists and is the one that has been created by the open call
>> isn't going to work.
>>
>> Something I don't understand from looking at the current devfs patch
>> is why the statfs call doesn't work. /dev/pts is still it's own
>> filesystem which has its own, well known magic value since devpts is
>> used - or is devfs not passing the calls through to devpts? Could
>> somebody enlighten me?
Richard> You're assuming that a devfs-system will still mount devpts on
Richard> /dev/pts, which is not necessarily the case (and is actually
Richard> undesirable). Devfs has a "live" implementation of /dev/pts. In fact,
Richard> devfs fully implemented a dynamic /dev/pts before devpts even existed.
Thanks for the clarification.
Does it always implement /dev/pts? Can I assume that /dev/pts is
available and working correctly if devfs is available?
Richard> So that's why glibc at least needs to check the magic number of /dev
Richard> and see if /dev/pts is a directory.
Ok.
Richard> But I still favour the speculative open method (get a master, then try
Richard> and open the slave in /dev/pts, if it fails, set a flag). It's robust
Richard> and allows alternative implementations of /dev/pts (such as a daemon).
Richard> Why don't you implement it this way?
IMHO that's even more ugly. We're discussing the getpt call which
returns just the fd of the master.
Btw. has anybody looked at the problematic situation and can confirm
whether this is a bug in devpts or not?
Andreas
P.S. From the GNU manual:
- Function: int getpt (void)
The `getpt' function returns a new file descriptor for the next
available master pseudo-terminal. The normal return value from
`getpt' is a non-negative integer file descriptor. In the case of
an error, a value of -1 is returned instead. The following
`errno' conditions are defined for this function:
`ENOENT'
There are no free master pseudo-terminals available.
This function is a GNU extension.
-- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/