Eric W. Biederman wrote: > Cedric Le Goater <clg at fr.ibm.com> writes: > >> 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. > > What is the important aspect that you need to group. What concept > are you trying to convey? > > How do you describe a container in which someone is using the > pam_namespace module? So different tasks in the container have > a different mount namespace? let's define a container first. I'm not sure for what you are using that term. >>> 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. > > The point is that there is not a one to one mapping between containers > and nsproxies. There are likely to be more nsproxies than containers. again. please explain the difference that you see between a container and a nsproxy. I don't get it and i might be missing something important doing this short cut. C.