[Devel] Re: [PATCH] make cr depend on all namespaces

Oren Laadan orenl at cs.columbia.edu
Mon Mar 15 15:09:48 PDT 2010



Serge E. Hallyn wrote:
> Quoting Oren Laadan (orenl at cs.columbia.edu):
>>
>> Serge E. Hallyn wrote:
>>> This should let us get rid of some ifdefed code and reduce
>>> chances for bad config combinations.  There's really no reason
>>> to support it.
>> I disagree.
>>
>> You are right that this will reduce the changes of bad config
>> combinations.
>>
>> However, it will also introduce some restrictions on the kernel
>> config which are unnecessary. Some people may not want to have
>> all namespaces configured.
> 
> Why?  The only reason right now to disable namespaces is for
> kernel size.

Yup.

So we know it works well when all ns are enabled. If there are
so few users that disable some ns, then we will rarely hear about
breakage anyway.

On the other hand - what about current distributions - do they
enable all namespaces by default ?  If not (mine didn't), then
potential tester will haev yet another barrier to testing since,
for instance, net-ns is disabled.

> 
>> Note that the namespaces are independent in the sense that we
>> don't need to test all combination of all namespaces - instead,
>> I consider turning on/off one at a time to be safe enough.
> 
> And do you do that?  :)  It still gets more complicated bc
> you have things like sysvipc and posix mq which both can allow
> ipc_ns.

You are 100% correct - we don't, and we should automate it.

I thought you intentionally leave out IPC in that patch...  ?

Anyway, ipc is the exception, because it can be disabled as a
whole. Can you do that on others ? (e.g. uts, user, etc)

> 
>> (FWIW, is it because you only wanted to show a point that you
>> only remove UTS_NS ifdefs ?)
> 
> It was just right there in my face...
> 
> Anyway if you don't take this patch then the UTS_NS code I
> removed should have 'name' put under ifdef to avoid a build
> warning.

Ok, will patch away and push to v20-rc2.

Oren.

_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list