[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48010C70.2030902@zytor.com>
Date: Sat, 12 Apr 2008 12:24:32 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
CC: Al Viro <viro@...IV.linux.org.uk>, sukadev@...ibm.com,
Andrew Morton <akpm@...l.org>, serue@...ibm.com,
matthltc@...ibm.com, Pavel Emelyanov <xemul@...nvz.org>,
Containers <containers@...ts.osdl.org>,
linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Multiple instances of devpts
Eric W. Biederman wrote:
>>
>> /dev/ptmx can be a symlink ptmx -> pts/ptmx, and we add a ptmx instance
>> inside the devpts filesystem. Each devpts filesystem is responsible for
>> its own pool of ptys, with own numbering, etc.
>>
>> This does mean that entries in /dev/pts are more than just plain device
>> nodes, which they are now (you can cp -a a device node from /dev/pts
>> into another filesystem and it will still "just work"), but I doubt this
>> actually matters to anyone. If anyone cares, now I guess would be a
>> good time to speak up.
>
> Agreed. That is another legitimate path. And if all you care about is
> isolation and not dealing with the general class of problems with the
> global device number to device mapping that is sane. I know we have
> several other virtual devices that we tend to care about but ptys are
> the real world pain point.
>
Thinking about it further, allowing this restriction would also allow a
whole lot of cleanups inside the pty setup, since it would eliminate the
need to do a separate lookup to find the corresponding devpts entry in
pty_open(). The benefit here comes from the closer coupling between the
pty and the devpts filesystem and isn't at all related to namespaces,
but it's a very nice side benefit.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists