Messages in this thread | | | Date | Thu, 16 Feb 2006 12:44:07 -0600 | From | "Serge E. Hallyn" <> | Subject | Re: (pspace,pid) vs true pid virtualization |
| |
Quoting Eric W. Biederman (ebiederm@xmission.com): > "Serge E. Hallyn" <serue@us.ibm.com> writes: > >> What happens when you migrate pspace 3 into a different pspace > >> on a different machine? > > > > Nothing special. "Migrate" was just a checkpoint (from pspace 1) > > and a resume (from pspace N on some machine). So now pspace N on > > the new machine has created a new pspace - which happens to be > > immediately populated with the contents of the old pspace 3 - and > > see the pid of the init process of this new pspace. > > > >> Is there a sane implementation for this? > > > > IMO, definately yes. > > > > But I haven't tried it, so my opinion is just that. > > If you are just talking the pid of the init process the problem seems > tractable. > > Where I see real problems with migration is and nested pid spaces > is when you expose all of your pids to your parent, and perhaps > there was some miscommunication on this point. > > To try and give an example. > > pspace 1 pspace 2 pspace 3 pspace 4 > pid 234 -> pid 1 > pid 235 -> pid 2 -> pid 1 > pid 236 -> pid 3 -> pid 2 -> pid 1 > > Hopefully this clearly shows what I was trying to avoid, by > only allow pid 1 of any pspace to be visible in the parent.
Yes, I saw it more like:
> pspace 1 pspace 2 pspace 3 pspace 4 > pid 234 -> pid 1 > pid 2 -> pid 1 > pid 2 -> pid 1 > pid 3
Now Dave and I were just talking about actually using the init process in a pspace to do administration from outside. For instance, the userspace code, in /sbin/pspaceinit, which runs as (pspace 2, pid 1), could open a pipe with it's parent (pspace1, pid 234). pid 234 can then ask the init process to do things like list processes, kill a process, and maybe even recursively talk to the init process in pspace 3.
-serge - 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/
| |