Re: RFC [patch 13/34] PID Virtualization Define new task_pid api

[Eric W. Biederman]

Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> writes:

> On Llu, 2006-01-23 at 12:28 -0700, Eric W. Biederman wrote:
>> > Yes, that's possible.. In the current patch that is not a problem, because
>> > the internal pid (aka kpid) == <vpid,containerid>  mangeled together.
>> > So in those cases, the kernel would have to keep <pid, container_id>
>> 
>> Agreed, and for the internal implementation I think having them mangled
>> together make sense, so long as we never export that form to userspace.
>
> You have to refcount the container ids anyway or you may have stale
> container references and end up reusing them.

The short observation is currently we use at most 22bits of the pid
space, and we don't need a huge number of containers so combining them
into one integer makes sense for an efficient implementation, and it
is cheaper than comparing pointers.

Additional identifiers are really not necessary to user space and providing
them is one more thing that needs to be virtualized.  We can already
talk about them indirectly by referring to processes that use them.

And there will be at least one processes id assigned to the pid space
from the outside pid space unless we choose to break waitpid, and friends.

I just don't want a neat implementation trick to cause us maintenance grief.

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/