Messages in this thread | | | Date | Mon, 23 Jan 2006 17:15:27 -0500 | From | Hubertus Franke <> | Subject | Re: 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/
| |