Re: (pspace,pid) vs true pid virtualization

["Serge E. Hallyn" <serue@us.ibm.com>]

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