Re: (pspace,pid) vs true pid virtualization

From: Kirill Korotaev
Date: Mon Feb 20 2006 - 04:20:04 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/