[OE-core] clarifying details about "is not set" lines in kernel config fragment files

[Bruce Ashfield]

On Tue, May 3, 2016 at 1:04 PM, Robert P. J. Day <rpjday at crashcourse.ca>
wrote:

>
>   oddly, in the current YP kernel dev manual, i don't see the phrase
> "is not set" explained anywhere in the entire doc, which is weird
> since it seems like it would be important.
>

The manuals don't cover the mechanics of how the mainline kernel is
configured.
Just the same way the don't cover the configuration language for any number
of packages in the system.


>
>   first, just to confirm *i* know what it's used for, it's not just a
> comment -- it's used explicitly by the kernel config process to
> stipulate that we are aware of a kernel config setting, and we don't
> want it. that is, if we have a kernel .config file used as the basis
> of a "make *config" command, and there is no mention whatever of a
> reachable config variable, the config process will stop and ask us
> about it. am i right so far?
>

Also correct. That's more upstream kernel configuration detail, not
something we duplicate.


>
>   this means that, once the kernel config process completes and the
> .config file is generated, every single *available* and *settable*
> kernel config option should be listed in the .config file, to avoid
> being asked about it the next time we do a kernel configuration.
>
>   oh, and about that "reachable" thing, we don't need a line regarding
> every single kernel config setting, just the ones that are available
> to be set given the current config settings. how am i doing so far?
>
>
Yep, and that means the final .config varies quite a bit, based on very
small
deltas in some config option.


>   given all that, my understanding is that, when one is writing kernel
> config fragments, it is necessary to explicitly deselect ("# ... is
> not set") *only* those kernel config options that would be selected
> based on other config settings we selected. do i have that right?
>

Nope.

If a Kconfig actually has "select FOO", you can't turn it off "FOO" no
matter how
hard you try. You need to turn off the option that has the select itself,
i.e. the
parent/containing option.

So you use # CONFIG_FOO is not set, to turn off your typical boolean or
tristate option, that may have a default 'y', or be otherwise enabled when
you
don't want it.


>
>   for instance, here's kernel Kbuild file net/Kconfig:
>
>
>     ...
>     menuconfig NETFILTER
>         bool "Network packet filtering framework (Netfilter)"
>         ... snip ...
>     if NETFILTER
>
>     config NETFILTER_DEBUG
>         bool "Network packet filtering debugging"
>         depends on NETFILTER
>         help
>           You can say Y here if you want to get additional messages useful
> in
>           debugging the netfilter code.
>
>
> as a test, i added a single-line frgament file:
>
>   CONFIG_NETFILTER=y
>
> however, even though NETFILTER_DEBUG was then selectable, because it
> wasn't *explicitly* selected, what i got in my final .config file was:
>
>     ...
>     CONFIG_NETFILTER=y
>     # CONFIG_NETFILTER_DEBUG is not set
>     ...
>
> however, because the very next Kconfig stanza was "default y":
>
>     config NETFILTER_ADVANCED
>         bool "Advanced netfilter configuration"
>         depends on NETFILTER
>         default y
>
> i *did* get the line in the final .config:
>
>     CONFIG_NETFILTER_ADVANCED=y
>
> does all this sound right? i always thought it was pretty
> straightforward, but i'm willing to be convinced i never really
> understood it.
>

Those are some relatively simple examples, but yes, pretty straight
forward. But no
one has ever claimed Kconfig to be simple or easy to fully grok.


>
>   and it does seem odd that it's not described anywhere in the YP
> kernel dev manual.
>

See above. We don't document what is already described in the mainline
kernel's
Kconfig specification.

Bruce


>
> rday
>
> --
>
> ========================================================================
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                         http://crashcourse.ca
>
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ========================================================================
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160503/bd02e314/attachment-0002.html>