Messages in this thread | | | Date | Mon, 8 Nov 1999 10:19:11 -0700 | From | Richard Gooch <> | Subject | Re: devfs v136, ZIP disks and glibc-2.1.2 |
| |
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?
You're assuming that a devfs-system will still mount devpts on /dev/pts, which is not necessarily the case (and is actually undesirable). Devfs has a "live" implementation of /dev/pts. In fact, devfs fully implemented a dynamic /dev/pts before devpts even existed.
So that's why glibc at least needs to check the magic number of /dev and see if /dev/pts is a directory.
But I still favour the speculative open method (get a master, then try and open the slave in /dev/pts, if it fails, set a flag). It's robust and allows alternative implementations of /dev/pts (such as a daemon). Why don't you implement it this way?
Regards,
Richard.... Permanent: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca
- 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/
| |