lkml.org 
[lkml]   [2006]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: (pspace,pid) vs true pid virtualization
From
Date
Sam Vilain <sam@vilain.net> 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 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/

\
 
 \ /
  Last update: 2006-02-16 06:56    [W:0.127 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site