Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx): > > > Serge E. Hallyn wrote: > >Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx): > >> > >>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. Thanks, I will fetch in a bit and re-test with your (presumably rebased) tree and report over irc. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
