Re: [RFC][PATCH 04/20] pspace: Allow multiple instaces of the process id namespace

[Kirill Korotaev <dev@sw.ru>]

>>Actually I can't say your patch is cleaner somehow.
>>It is very big and most of the changes are trivial, which creates an illusion
>>that it is straightforward and clean.
> 
> 
> It is hard to make a comparison.  Your patch posted to the mail list
> was incomplete, and I could only find a giant patch for OpenVZ.
this is wrong. it lacked only alpha get_xpid().
sure, we didn't do that dirty games with /proc you did, so maybe this is 
why you have such a feeling.

> Beyond that if your patch introduced a type change for internal pids
> and used that generate compile errors when someone did not use the
> appropriate type, I would be a lot happier and the code would
> be a lot more maintainable.  I.e. It would not take an audit of
> the kernel source to find the issues an allyesconfig build would find
> them for you.
it is not a problem at all and can be done.

> I don't think my current implementation actually causes enough compile
> errors, but I need think closely about it before I go much farther.
> 
> Maintainable code is a delicate balancing act between things that
> trip you up when you get it wrong, and not being so cumbersome you
> get in the programmers way

> The advantages I see with my approach.
> - I have hierarchical pids so nesting is possible.
Once again, our approach doesn't prohibit hierarchical pids.
But in addition to yours it allows to select whether weak or strong 
isolation is required.

> - The state after migration is not suboptimal.
sorry?

> - I cause compiler errors which makes maintenance easier.
it is not a question to the approach itself, you see? so not an argument.

> - Other kernel developers gut feel is that (container, pid) is the proper
>   representation.  
>   I actually flip flop on the issue of if I want the internal representation
>   to be (container, pid) or a magic kpid that combines the into one integer.
>   I know I don't want the kpid to be user space visible though.
> 
> So far you have not addressed the issues of maintaining code in the
> kernel tree.  
Uhhh... I see that you have no real arguments. Nice.

Kirill