On Tue, May 3, 2016 at 1:04 PM, Robert P. J. Day <rpj...@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@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"
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core