On Fri, Feb 9, 2018 at 4:46 AM, Ulf Magnusson <ulfalizer@xxxxxxxxx> wrote: > One thing that makes Kconfig confusing (though it works well enough in > practice) is that .config files both record user selections (the saved > configuration) and serve as a configuration output format for make. > > It becomes easier to think about .config files once you realize that > assignments to promptless symbols never have an effect on Kconfig > itself: They're just configuration output, intermixed with the saved > user selections. > > Assume 'option env' symbols got written out for example: > > - For a non-user-assignable symbol, the entry in the .config > file is just configuration output and ignored by Kconfig, > which will fetch the value from the environment instead. > > - For an assignable 'option env' symbol, the entry in the > .config file is a saved user selection (as well as > configuration output), and will be respected by Kconfig. In the stack-protector case, this becomes quite important, since the goal is to record the user's selection regardless of compiler capability. For example, if someone selects _REGULAR, it shouldn't "upgrade" to _STRONG. (Similarly for _NONE.) Having _AUTO provides a way to pick "best possible for this compiler", though. If a user had previously selected _STRONG but they're doing builds with an older compiler (or a misconfigured newer compiler) without support, the goal is to _fail_ to build, not silently select _REGULAR. So, in this case, what's gained is the logic for _AUTO, and the logic to not show, say, _STRONG when it's not available in the compiler. But we must still fail to build if _STRONG was in the .config. It can't silently rewrite it to _REGULAR because the compiler support for _STRONG regressed. -Kees -- Kees Cook Pixel Security -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
