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