Cedric Le Goater <clg@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
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers