Quoting Cedric Le Goater (clg at fr.ibm.com): > Dave Hansen wrote: > > On Mon, 2006-12-11 at 16:23 +0100, Cedric Le Goater wrote: > >>> 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. > >> i don't agree here. we need that, so does openvz, vserver, people working > >> on resource management. > > > > I think what those projects need is _some_ way to group tasks. I'm not > > sure they actually need nsproxies. > > not only tasks. ipc, fs, etc. > > > Two tasks in the same container could very well have different > > nsproxies. The nsproxy defines how the pid namespace, and pid<->task > > mappings happen for a given task. > > not only. there are other namespaces in nsproxy. Right, and as Eric has pointed out, you may well want to use one id to refer to several nsproxies - for instance if you are using unshare to provide per-user private mount namespaces using pam_namespace.so (that's mostly for LSPP systems right now, but I do this on my laptop too). All my accounts are in the same 'container', but have different mount namespaces, hence different nsproxies. > > The init process for a container is > > special and might actually appear in more than one pid namespace, while > > its children might only appear in one. That means that this init > > process's nsproxy can and should actually be different from its > > children's. This is despite the fact that they are in the same > > container. > > > > If we really need this 'container' grouping, it can easily be something > > pointed to _by_ the nsproxy, but it shouldn't _be_ the nsproxy. > > ok so let's add a container object, containing a nsproxy and add > another indirection ... No thanks.