[Devel] Re: [patch -mm 08/17] nsproxy: add hashtable
Eric W. Biederman
ebiederm at xmission.com
Fri Dec 8 12:57:38 PST 2006
"Serge E. Hallyn" <serue at us.ibm.com> writes:
> Quoting Eric W. Biederman (ebiederm at xmission.com):
>> clg at fr.ibm.com writes:
>>
>> > From: Cedric Le Goater <clg at fr.ibm.com>
>> >
>> > This patch adds a hashtable of nsproxy using the nsproxy as a key.
>> > init_nsproxy is hashed at init with key 0. This is considered to be
>> > the 'host' nsproxy.
>>
>> NAK. Which namespace do these ids live in?
>>
>> It sounds like you are setting up to make the 'host' nsproxy special
>> and have special rules. That also sounds wrong.
>>
>> Even letting the concept of nsproxy escape to user space sounds wrong.
>> nsproxy is an internal space optimization. It's not struct container
>> and I don't think we want it to become that.
>>
>> Eric
>
> So would you advocate referring to containers just by the pid of a
> process containing the nsproxy, and letting userspace maintain a mapping
> of id's to containers through container create/enter commands? Or is
> there some other way you were thinking of doing this?
There are two possible ways.
1) Just use a process using the namespace.
This is easiest to implement.
2) Have a struct pid reference in the namespace itself, and probably
an extra pointer in struct pid to find it.
This is the most stable, because fork/exit won't affect which pid you need
to use.
Beyond that yes it seems to make sense to let user space maintain any mapping
of containers to ids.
Eric
_______________________________________________
Containers mailing list
Containers at lists.osdl.org
https://lists.osdl.org/mailman/listinfo/containers
More information about the Devel
mailing list