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

[Hubertus Franke]

Eric W. Biederman wrote:
> 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

In that case, I think we do require the current vpid_to_pid(translations)
in order to transfer the external user pid ( relative to the namespace )
into one that combines namespace (aka container_id) with the external pid.
Exactly how it is done today.
What will slightly change is the low level implementations of the

inline pid_t pid_to_vpid_ctx(pid_t pid, const struct task_struct *ctx);
pid_t __pid_to_vpid_ctx_excp(pid_t pid, int pidspace_id,const struct task_struct *ctx);

and reverse.
The VPID_2_PID and PID_2_VPID still remain at same locations.

Did I get your comments correctly, Eric ?..

Thanks as usual
-- Hubertus



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