Cedric Le Goater <clg@fr.ibm.com> writes:

> Eric W. Biederman wrote:
>> This reverts commit 373beb35cd6b625e0ba4ad98baace12310a26aa8.
>> 
>> No one is using this identifier yet.  The purpose of this identifier
>> is to export nsproxy to user space which is wrong.  nsproxy is
>> an internal implementation optimization, which should keep our
>> fork times from getting slower as we increase the number of global
>> namespaces you don't have to share.
>> 
>> Adding a global identifier like this is inappropriate because it makes
>> namespaces inherently non-recursive, greatly limiting what we can
>> do with them in the future.
>
> Future will tell us, until then, let's see how useless and buggy this non
> feature is. 
>
> So for the moment, I would keep it and let people experiment.

Even if the id is a sane idea nsproxy is very much the wrong place to
put it.  nsproxy is an optimization so we don't bloat task struct with
several additional pointers, and it keeps fork times under control because
in the normal case we only have a single increment instead of several.
I'm not fully convinced it isn't a pessimization because it adds an
extra indirection.  It is fully inappropriate to export that to user
space.

Now I don't mind a little experimentation but not in the stable kernel
when several people disagree.

To a very large degree adding an id to struct nsproxy violates the compromise
we came to when we agreed to add nsproxy.

I am willing to discuss this but not while it is silently being added
to the user interface and being exported to userspace in a way we have
to support for the forseeable future.  To that I strongly object.

The fact that it is simply dead code for 2.6.20 is probably sufficient
justification to revert it until we can agree.

Eric
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers