Alan Cox <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Alan Cox <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Hubertus Franke <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- References:
- RFC [patch 00/34] PID Virtualization Overview
- From: Serge Hallyn <[email protected]>
- RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Serge Hallyn <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Arjan van de Ven <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: "Serge E. Hallyn" <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Alan Cox <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Dave Hansen <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Greg KH <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Dave Hansen <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: [email protected] (Eric W. Biederman)
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Hubertus Franke <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: [email protected] (Eric W. Biederman)
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Hubertus Franke <[email protected]>
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: [email protected] (Eric W. Biederman)
- Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- From: Alan Cox <[email protected]>
- RFC [patch 00/34] PID Virtualization Overview
- Prev by Date: Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
- Next by Date: Re: [PATCH 9/9] device-mapper snapshot: fix invalidation
- Previous by thread: Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- Next by thread: Re: RFC [patch 13/34] PID Virtualization Define new task_pid api
- Index(es):
 |