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

[Serge E. Hallyn]

Quoting Paul Jackson (pj@xxxxxxx):
> Serge wrote:
> > But when one of the
> > processes looks for process 10, task_vpid_to_pid(current, 10) will return
> > the real pid for the vpid 10 in current's pidspace.
> 
> So a "kill -1 10" will mean different things, depending on the pidspace
> that the kill is running in.  And pid's passed about between user
> tasks as if they were usable system-wide are now aliased by their
> invisible pidspace.
> 
> Yuck.  Such virtualizations usually have a much harder time addressing
> the last 10% of situations than they did the easy 90%.

For simplicity, the only pids a process will see are those in its own
pidspace, and the only controls (I expect) will be the ability to start
a new pidspace, and request a pid.  So it is no more complicated than
the vserver model, where a process becomes pid 1 only for other proceses
in the same vserver, and process don't see processes in other vservers -
except that now every process in the pidspace can be known as a different
pid, not just the first.

> How about instead having a way to put the pid's of checkpointed tasks
> in deep freeze, saving them for reuse when the task restarts?
> System calls that operate on pid values could error out with some
> new errno, -EFROZEN or some such.

Unfortunately that would not work for checkpoints across boots, or, more
importantly, for process (set) migration.

> This would seem far less invasive.  Not just less invasive of the code,
> but more importantly, not introducing some never entirely realizable
> semantic change to the scope of pids.

Hopefully the next patchset, implementing the pid-vpid split, will show
it's not as complicated as I've made it sound.

Of course, if it remains too complicated a conceptual change to be
mergeable, we're better off knowing that now...

thanks,
-serge
-
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/