This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: multiple devpts mounts not supported insysdeps/unix/sysv/linux/ptsname.c:_ptsname_internal()
- From: "Serge E. Hallyn" <serge dot hallyn at canonical dot com>
- To: Andreas Schwab <schwab at linux-m68k dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 11 Oct 2011 16:04:05 -0500
- Subject: Re: multiple devpts mounts not supported insysdeps/unix/sysv/linux/ptsname.c:_ptsname_internal()
- References: <20111011171537.GA12661@sergelap><m2ty7fxq0r.fsf@igel.home>
Quoting Andreas Schwab (schwab@linux-m68k.org):
> "Serge E. Hallyn" <serge.hallyn@canonical.com> writes:
>
> > grantpt, ptsname, and ptsname_r make use of _ptsname_internal(). That
> > function works by appending the TIOCGPTN result to "/dev/pts". The
> > path /dev/pts is hardcoded. That means that if you call grantpt on an
> > fd from /chroot/dev/pts, and /dev/pts/0 (for instance) does not exist
> > on the host, you'll (wrongly) get back an error. This has been seen with
> > libvirt (and is easly to verify with a simple testcase).
>
> If you want to use /dev/pts from the chroot you must run grantpt in the
> chroot. Since getpt or posix_openpt always returns an fd from the
> system /dev/pts this is not an unreasonable restriction.
Ok (I suspected that would be the feeling :). I think it's unfortunate
but not unreasonable. I think the manpages are unreasonable (since
getpt says it's equivalent to open("/dev/ptmx", ..., and grantpt says
nothing about restrictions on the passed-in fd), but as Mike points out
those are not maintained here :)
So I'll pursue a manpage update.
thanks,
-serge