[PATCH 09/10] Enable multiple instances of devpts
Cedric Le Goater
clg at fr.ibm.com
Mon Sep 29 08:58:14 PDT 2008
>> | > The logic seems simple: With newinstance create a private namespace.
>> | > Without newinstance, bind to initial ns.
>> | But if I'm in a container in a new mounts ns and somehow managed
>> | to umount -l /dev/pts, shouldn't i be able to remount my container's
>> | devpts by just doing 'mount -t devpts devpts /dev/pts'?
yes. That's the track we are following with the mq namespace.
>> Now wouldn't that require us to associate the devpts mount with some
>> notion of a container ? (a namespace object in nsproxy of container-init
>> like we do with /proc).
and it gets a little bit ugly because you need to maintain an internal
mount associated with the namespace to be able to remount the same
superblock when a :
$ umount /dev/pts
$ mount -t devpts devpts /dev/pts'?
So if you're using the mount option 'newinstance' to unshare the
namespace, you end up doing the internal mount and the user mount
under the same call, which is a bit weird, indeed.
>> Yes, after 'umount -l' we have lost _that_ devpts ns and we may have to
>> 'redo' the relevant container-init parts
> It all just feels fragile.
> I realize this is an attempt to do the 'pure fs approach' you were asked
> to do. I just don't like the resulting
More information about the Containers