Re: [RFC] [PATCH 00/13] Introduce task_pid api

[Eric W. Biederman]

"Serge E. Hallyn" <serue@xxxxxxxxxx> writes:

> --
>
> I'm part of a project implementing checkpoint/restart processes.
> After a process or group of processes is checkpointed, killed, and
> restarted, the changing of pids could confuse them.  There are many
> other such issues, but we wanted to start with pids.
>
> Does something like this, presumably after much working over, seem
> mergeable?

This set of patches looks like a global s/current->pid/task_pid(current)/
Which may be an interesting exercise but I don't see how this
helps your problem.  And as has been shown by a few comments
this process making all of these changes is subject to human error.

Many of the interesting places that deal with pids and where you
want translation are not where the values are read from current->pid,
but where the values are passed between functions.  Think about
the return value of do_fork.

There are also a lot of cases you haven't even tried to address.
You haven't touched process groups, or sessions.

At the current time the patch definitely fails the no in kernel
users test because it doesn't go as far as taking advantage
of the abstraction it attempts to introduce.  Which means
other people can't read through the code and make sense
of what you are trying to do or to see if there is a better way.

I will also contend that walking down a path that does not cause
compilation to fail when the subtle things like which flavor of
pid you want to see is a problem.

Another question is how do your pid spaces nest.  Currently
it sounds like you are taking the vserver model and allowing
everyone outside your pid space to see all of your internal
pids.  Is this really what you want?  Who do you report as
the source of your signal.  

What pid does waitpid return when the parent of your pidspace exits?
What pid does waitpid return when both processes are in the same pidspace?

How does /proc handle multiple pid spaces?

While something allowing multiple pidspaces may be mergeable,
unnecessary and incomplete changes rarely are.  This is a fundamental
change to the unix API so it will take a lot of scrutiny to get
merged.

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