Messages in this thread | | | Subject | Re: [RFC][PATCH 04/20] pspace: Allow multiple instaces of the process id namespace | From | (Eric W. Biederman) | Date | Sat, 11 Feb 2006 04:03:43 -0700 |
| |
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/
| |