lkml.org 
[lkml]   [2006]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFC [patch 13/34] PID Virtualization Define new task_pid api
Eric W. Biederman wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-01-23 23:17    [W:0.407 / U:0.640 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site