Sam Vilain <[email protected]> writes:
> Serge E. Hallyn wrote:
>> However, if we're going to get anywhere, the first decision which we
>> need to make is whether to go with a (container,pid), (pspace,pid) or
>> equivalent pair like approach, or a virtualized pid approach. Linus had
>> previously said that he prefers the former. Since there has been much
>> discussion since then, I thought I'd try to recap the pros and cons of
>> each approach, with the hope that the head Penguins will chime in one
>> more time, after which we can hopefully focus our efforts.
>
> IOW, we can stop arguing and start implementing :-).
PID Space god mode....
If internally each pspace had a small number, that we could prepend
to the pid. We would have a local global pid view.
If we hashed each pid by the unsigned long version of pspace->nr | pid.
We would have a hash table with a global view.
If we exported this number to user space we would have global pids.
I absolutely hate the idea because it yields a set of processes whose
view of the world is difficult if not impossible to migrate to another
machine, plus those processes need an extra set of translation functions.
It is worth mentioning because it is easy to implement, and either everyone
else will like it and it will get adopted or it will at least provide
an easy way to implement a transition API, for those people currently stuck.
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]
