Kirill Korotaev <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
