Re: devfs v136, ZIP disks and glibc-2.1.2

Richard Gooch (rgooch@ras.ucalgary.ca)
Mon, 8 Nov 1999 10:19:11 -0700

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/