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? >> 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. >> 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 ... Well that isn't what Dave suggested, and I don't think it will give you what you want. Eric
