Eric W. Biederman wrote:
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
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
