Re: (pspace,pid) vs true pid virtualization

[Hubertus Franke <frankeh@watson.ibm.com>]

Serge E. Hallyn wrote:
> Quoting Eric W. Biederman (ebiederm@xmission.com):
> 
>>"Serge E. Hallyn" <serue@us.ibm.com> writes:
>>With respect to pids lets not get caught up in the implementation
>>details.  Let's first get clear on what the semantics should be.
>>
>>- Should the first pid in a pid space have pid 1?
that should only be required if you have system containers
or if there are tools or requirements that if I wonderup my process tree
that I ultimately must end up at 1.
>>
>>- Should pid == 1 ignore signals, it doesn't have a handler for?

Yes
>>
>>- Should any children of pid 1 be allowed to live when pid == 1 is killed?
No  .. it has init semantics !

> 
> 
> But doesn't that depend on whether we use (pspace,pid) or vpids?  If
> vpids, then init isn't really a problem, since from kernelspace
> processes in a comtainer stil have a global pid and global parent, and
> init knows them.  If (pspace,pid), then we need a fakeinit bc the real
> init doesn't know about the processes in the container...
> 
> 
>>- Should a process have some sort of global (on the machine identifier)?

First establish whether that global ID has to be persistent ...
I don't see why ! In which case the TASK_REF is the perfect global ID.
> 
> 
> I think to satisfy openvz existing customers this must be a yes.  With
> vpid the answer is simple.  With (pspace,pid), there are three anwers i've
> heard, namely
> 
> 	1. just use pspaceid, pid
> 	2. make pspaceid small and use (pspaceid << SOMEBITS | pid)
> 	3. use pid1/pid2/pid3 where pid1 is creator of pid and its
> 	pspace, etc...
This implies that pid2 can be looked up in the context of pid1.
In OpenVZ approach that's possible, In pspaces.. isn't that the wpid ?

> 
> But the openvz guys also don't want userspace tool changes, making (2)
> the most likely option.  Any other ideas?
> 
> 
>>- Should the pids in a pid space be visible from the outside?
> 
> 
> Again, the openvz guys say yes.
> 
> I think it should be acceptable if a pidspace is visible in all it's
> ancestor pidspaces.  I.e. if I create pspace2 and pspace3 from pid 234
> in pspace1, then pspace2 doesn't need to be able to address pspace3
> and vice versa.

That means you need to do a more complicated lookup ! for instance let's say you have hierarchy
pspace1
    |--->pspace2
    |       |--->pspace2a
    |--->pspace3	
            |--->pspace3a

let's assume we use the (pspaceid<<BITS | pid ) global id. To verify I have to
ensure that the target pid can reach the originating pid in its ancestor path.
Not a biggy as these pspace trees probably won't get much deeper then 3 or 4.

> 
> Kirill, is that acceptable?
> 
> 
>>- Should the parent of pid 1 be able to wait for it for it's 
>>  children?
> 
> Yes.

Yes ... VPID does that and wpid in pspace does that as well.
> 
> 
>>- Is a completely disjoin pid space acceptable to anyone?
> 
> 
> To anyone?  yes  :)
> 
> TO everyone, I don't think so.
> 
hehh...   yes they should be disjoined other then at the top
where we want to wait ..
> 
>>- What should the parent of pid == 1 see?
>>
>>- Should a process not in the default pid space be able to create 
>>  another pid space?
> 
> 
> Yes.

How else do you get hierarchy ....

> 
> This is to support using pidspaces for vservers, and creating
> migrateable sub-pidspaces in each vserver.
> 
> 
>>- Should we be able to monitor a pid space from the outside?
> 
> 
> To some extent, yes.
> 
> 
>>- Should we be able to have processes enter a pid space?
> 
> 
> IMO that is crucial.

Existing ones .. now that is potentially difficult to do. Particular
if you want to enter a pidspace that has already been migrated.
Because ones assigned pid might already been taken in the target pspace.

> 
> 
>>- Do we need to be able to be able to ptrace/kill individual processes
>>  in a pid space, from the outside, and why?
> 
> 
> I think this is completely unnecessary so long as a process can enter a
> pidspace.
> 
> 
>>- After migration what identifiers should the tasks have?
> 
> 
> It must be possible to retain the same pids, at least from inside the
> container.

Absolutely .. otherwise all cashed pids in userspace are meaningless.

> 
> So this is irrelevant, as the openvz approach can just virtualize the
> old pid, while (pspace, pid) will be able to create a new container and
> use the old pid values, which are then guaranteed to not be in use.

Exactly .. mute issue, this is "trivial" as long as you can fork with
a particular pid used.

> 
> 
>>If we can answer these kinds of questions we can likely focus in
>>on what the implementation should look like.  So far I have not
>>seen a question that could not be implemented with a (pspace, pid)/pid
>>or a vpid/pid implementation.
> 
> 
> But you have, haven't you?  Namely, how can openvz provide it's
> customers with a global view of all processes without putting 5 years of
> work into a new sysadmin interface?
> 
> -serge
>