Eric W. Biederman wrote:
> Kirill Korotaev <dev at sw.ru> writes:
>>>> I think what those projects need is _some_ way to group tasks. I'm not
>>> sure they actually need nsproxies.
>>>>>> Two tasks in the same container could very well have different
>>> nsproxies.
>> what is container then from your POV?
>> A nested instance of user space. User space may unshare things
> such as the mount namespace so it can give users the ability to
> control their own mounts and the like.
>>>> The nsproxy defines how the pid namespace, and pid<->task
>>> mappings happen for a given task. 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.
>> nsproxy has references to all namespaces, not just pid namespace.
>> Thus it is a container "view" effectively.
>> If container is something different, then please define it.
>> nsproxy has exactly one instance of all namespaces. A container
> in the general case can hold other containers, and near containers
> (like processes with separate mount namespaces). As well as
> processes.
>> So nsproxy currently captures the common case for containers but not
> the general case.
i don't see the difference. honestly. what is the general case ? the full
system holding all the instances of all the namespaces ? but that's not
usable by user space. you need only one instance of all namespaces, not all.
I don't get it. we don't want the general case to be exposed to user space
we only want one instance == nsproxy.
C.