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

From: Kirill Korotaev
Date: Mon Feb 13 2006 - 03:58:46 EST

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.

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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at