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.

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.

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.
- The state after migration is not suboptimal.
- I cause compiler errors which makes maintenance easier.
- 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.  

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/