Re: (pspace,pid) vs true pid virtualization

[Kirill Korotaev <dev@sw.ru>]

Hello,

> 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?
yup.

> - Should pid == 1 ignore signals, it doesn't have a handler for?
yup.

> - Should any children of pid 1 be allowed to live when pid == 1 is killed?
nope. you have this problem in your code, when child_reaper references 
freed task.

> - Should a process have some sort of global (on the machine identifier)?
yep. otherwise it is imposible to manage (ptrace, kill, ...) it, without 
introducing new syscalls.

> - Should the pids in a pid space be visible from the outside?
This can be done tunable, but this is VERY highly desired.
This also makes introducing many new syscalls unneeded.

> - Should the parent of pid 1 be able to wait for it for it's 
>   children?
What for? This doesn't guarantee any completion of the container destroy.

> - Is a completely disjoin pid space acceptable to anyone?
no, not acceptable for us :)

> - What should the parent of pid == 1 see?
if pidspaces are fully isolated it should see nothing (otherwise, it is 
still weak isolation, as host admin will be able to get access to the 
container).
if pidspaces are weak isolated it should see the whole process tree.

> - Should a process not in the default pid space be able to create 
>   another pid space?
optional. I really can hardly see it's usecases, if any...
Yes, I remember some talks about checkpointing of group of processes, 
but this doesn't help it, believe me (ask Kuznetsov :) )...

> - Should we be able to monitor a pid space from the outside?
Yes. We strongly beleive we need it.

> - Should we be able to have processes enter a pid space?
Yes. The same.

> - Do we need to be able to be able to ptrace/kill individual processes
>   in a pid space, from the outside, and why?
Yes. This is very helpful management feature. Otherwise you won't be 
able to resolve issues with containers. Why it stuck? For example, after 
checkpoint/restore how do plan to debug it?

> - After migration what identifiers should the tasks have?
pids? in pspace it should the same pids which were assigned to them on 
fork(). in host they can have any other pid allocated.

> 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.
It seems to me that we still talk too much about PID spaces, while this 
is not the most problematic thing. This can be out of tree for some time 
if required.

> I think it is safe to say that from the inside things should look to
> processes just as they do now.  Which answers a lot of those
> questions.  But it still leaves a lot open.

Kirill

-
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/