[Devel] Re: [PATCH 0/13] Pid namespaces (OpenVZ view)
Pavel Emelianov
xemul at sw.ru
Thu May 24 09:15:55 PDT 2007
Serge E. Hallyn wrote:
> Quoting Pavel Emelianov (xemul at openvz.org):
>> That's how OpenVZ sees the pid namespaces.
>>
>> The main idea is that kernel keeps operating with tasks pid
>> as it did before, but each task obtains one more pid for each
>> pid type - the virtual pid. When putting the pid to user or
>> getting the pid from it kernel operates with the virtual ones.
>>
>> E.g. virtual pid is returned from getpid(), virtual pgid -
>> from getpgid() and so on. Getting virtual pid from user is
>> performed in setpgid(), setsid() and kill() mainly and in some
>> other places.
>>
>> As far as the namespace are concerned I propose the following
>> scheme. The namespace can be created from unshare syscall only.
>> This makes fork() code look easier. Of course task must be
>
> So is your main reason for posting this as a counter to Suka's patchset
> the concern of overhead at clone?
No, that's just a coincidence that I worked on the same problem.
What I propose is another way to make pid namespaces. It has its
advantages over Suka's approach. Main are:
1. Lighter exporting of pid to userspace and performance issues
on the whole - as you have noticed at least fork() is
lighter and many syscalls that return task pids are;
2. Kernel logic of tracking pids is kept - virtual pids are
used on kernel-user boundary only;
3. Cleaner logic for namespace migration: with this approach
one need to save the virtual pid and let global one change;
with Suka's logic this is not clear how to migrate the level
2 namespace (concerning init to be level 0).
> thanks,
> -serge
More information about the Devel
mailing list