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

[ebiederm@xmission.com (Eric W. Biederman)]

Kirill Korotaev <dev@sw.ru> writes:

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

Not at all.
- You didn't have a system call interface.
- You didn't include your patches to proc.
- The fact that you missed several whole subsystems, (as did I)
  is a minor issue.
etc.

The patches we posted were a different subset of the whole, and as such
a clear comparison could not be made.

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

Then why isn't it done in OpenVZ?

I agree it can be done.  But an audit of the entire kernel is painful.

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

Again. I have not heard this assertion before, and I don't see it.
But let me ask a question that helps frame the issue.

Can I migrate all of the processes and (containers) on a real server
(not in a container) into a container on another machine without
any change in pids?

I believe that would require 3 on the inner most nested processes with
your approach.


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

You have 2 approaches, in your patch.  I have one approach that works
for everything.  Possibly I misunderstood my skimming, but usually
optimizations are only added when needed.

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

How the code will be maintained when discussing merging with the mainline
kernel is one of the most important issues to consider.

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

I wasn't trying to argue simply to lay it out as I saw it.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/