[PATCH 09/10] Enable multiple instances of devpts

[Cedric Le Goater]

>> | > 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).
> 
> Yes.

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'?

is done.

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.

C.

>> 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