> 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.

yes and so ?
 
> 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.

this is not exported to user space yet.

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

yeah, i'm not sure how to understand that "several".
 
> To a very large degree adding an id to struct nsproxy violates the compromise
> we came to when we agreed to add nsproxy.

compromise ... you should say eric's capitulation ;)

> I am willing to discuss this but not while it is silently being added

you're in cc:

> 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.

again : this is not exported to user space yet. 

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

ok. i'll keep adding it to the patchset. 

thanks for your positive contribution, 

C, lightly upset but will not surrender.
_______________________________________________
Containers mailing list
Containers@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers