Quoting Eric W. Biederman (ebiederm at xmission.com): > clg at fr.ibm.com writes: > > > From: Cedric Le Goater <clg at fr.ibm.com> > > > > This patch adds a hashtable of nsproxy using the nsproxy as a key. > > init_nsproxy is hashed at init with key 0. This is considered to be > > the 'host' nsproxy. > > NAK. Which namespace do these ids live in? > > It sounds like you are setting up to make the 'host' nsproxy special > and have special rules. That also sounds wrong. > > Even letting the concept of nsproxy escape to user space sounds wrong. > nsproxy is an internal space optimization. It's not struct container > and I don't think we want it to become that. > > Eric So would you advocate referring to containers just by the pid of a process containing the nsproxy, and letting userspace maintain a mapping of id's to containers through container create/enter commands? Or is there some other way you were thinking of doing this? thanks, -serge
