Re: [PATCH 1/5] The config option itself

From: Pavel Emelyanov
Date: Mon Oct 01 2007 - 10:32:08 EST


Serge E. Hallyn wrote:
> Quoting Pavel Emelyanov (xemul@xxxxxxxxxx):
>> sukadev@xxxxxxxxxx wrote:
>>> Serge E. Hallyn [serue@xxxxxxxxxx] wrote:
>>> | Quoting Serge E. Hallyn (serue@xxxxxxxxxx):
>>> | > Quoting Pavel Emelyanov (xemul@xxxxxxxxxx):
>>> | > > The option is called NAMESPACES. It can be selectable only
>>> | > > if EMBEDDED is chosen (this was Eric's requisition). When
>>> | > > the EMBEDDED is off namespaces will be on automatically.
>>> | > >
>>> | > > One more option (NAMESPACES_EXPERIMENTAL) was added by
>>> | > > Serge's request to move there all the namespaces that are
>>> | > > not finished yet. Currently only the user and the network
>>> | > > namespaces are such.
>>> | > >
>>> | > > Signed-off-by: Pavel Emelyanov <xemul@xxxxxxxxxx>
>>> | > >
>>> | > > ---
>>> | > >
>>> | > > diff --git a/init/Kconfig b/init/Kconfig
>>> | > > index 684ccfb..05a71d7 100644
>>> | > > --- a/init/Kconfig
>>> | > > +++ b/init/Kconfig
>>> | > > @@ -369,6 +360,23 @@ config RELAY
>>> | > >
>>> | > > If unsure, say N.
>>> | > >
>>> | > > +config NAMESPACES
>>> | > > + bool "The namespaces support" if EMBEDDED
>>> | > > + default !EMBEDDED
>>> | > > + help
>>> | > > + Provides the way to make tasks work with different objects using
>>> | > > + the same id. For example same IPC id may refer to different objects
>>> | > > + or same user id or pid may refer to different tasks when used in
>>> | > > + different namespaces.
>>> | > > +
>>> | > > +config NAMESPACES_EXPERIMENTAL
>>> | > > + bool "Add the experimantal namespaces support" if EMBEDDED
>>> | >
>>> | > Hi Pavel,
>>> | >
>>> | > Overall this patchset looks good.
>>> | >
>>> | > However the NAMESPACES_EXPERIMENTAL option should not have the
>>> | > 'if EMBEDDED', right? This is about EXPERIMENTAL, not about
>>> | > EMBEDDED, unlike the plain NAMESPACES option.
>>> | >
>>> | > -serge
>>> |
>>> | Actually that doesn't seem to work either. Even though
>>> | SECURITY_NAMESPACES=y, the config system seems to infer that
>>> | since NAMESPACES is not user-selectable, NAMESPACES_EXPERIMENTAL
>>> | shouldn't be either. So we end up with NAMESPACES_EXPERIMENTAL
>>> | being on and not un-selectable if !EMBEDDED.
>>>
>>> Yes. Given that NAMESPACES depends on EMBEDDED, NAMESPACES_EXPERIMENTAL
>>> can simply depend on NAMESPACES and EXPERIMENTAL with a default of N.
>> Nope. The intention is that the NAMESPACES and NAMESPACES_EXPERIMENTAL
>
> No, Eric wanted NAMESPACES to only be unselecteable if EMBEDDED=y, but
> NAMESPACES_EXPERIMENTAL should always be unselectable. If current
> config logic can't do that then we should forget about the EMBEDDED
> requirement altogether.

OK, I see and agree :) I will remake the patches shortly.

> The rest of this patchset looks great. Thanks, Pavel.

You're welcome.

> -serge
>
>> must not be selectable if EMBEDDED=n, but if we make NS_EXPERIMENTAL
>> depend on NAMESPACES only we'll have to make a choice in !EMBEDDED.
>>
>>> BTW, does the position of 'config NAMESPACES' in init/Kconfig file
>>> matter ? If it is dependent on EMBEDDED, should it not come later
>>> in the file, after 'config EMBEDDED' ?
>>>
>>> |
>>> | > > + depends on NAMESPACES && EXPERIMENTAL
>>> | > > + default !EMBEDDED
>>> | > > + help
>>> | > > + Also include the support for the namespaces that are not fnished
>>> | > > + or well developed yet
>>> | > > +
>>> | > > config BLK_DEV_INITRD
>>> | > > bool "Initial RAM filesystem and RAM disk (initramfs/initrd) support"
>>> | > > depends on BROKEN || !FRV
>>> | _______________________________________________
>>> | Containers mailing list
>>> | Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
>>> | https://lists.linux-foundation.org/mailman/listinfo/containers
>>>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/