*thread necromancy* On Fri, Dec 9, 2016 at 11:40 AM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, Dec 9, 2016 at 11:12 AM, Kees Cook <keescook@xxxxxxxxxx> wrote: >> I'm starting to wonder if we need to expose the compiler version to >> Kconfig so that "all*config" builds for earlier compiler will >> automatically leave things like plugins off. But I have no idea what >> the right approach for that might be. > > We had some broken mock-up of a config option that did a "system()" > call to do some shell scripting for filling in config options (ie turn > a fail/pass into false/true boolean automatically with something like > > config COMPILER_SUPPORTS_XYZ > bool > option shell="gcc -XYZ" > > The idea is really solid: move a lot of the nasty ad-hoc runtime > testing in the Makefiles to the configuration stage. I would seriously > like to see this, so that we could replace the stupid > > CFLAGS_KCOV := $(call cc-option,-fsanitize-coverage=trace-pc,) > > with just nicer thing (ok, that's a bad example, but some of the other > cc-option cases are really pretty fundamental to kernel configuration, > and it really matters whether the compiler supports something or not). > > The main problem was actually that we don't have good infrastructure > for passing in the compiler environment etc to kbuild. > > I forgot who did that mock-up (and what the exact syntax was), but it > was pretty simple. Yeah, agreed; I would love this for much more than just gcc plugins. I'd rather that compiler-specific things were Kconfig-sane with discoverable reasons for a Kconfig being unavailable. Does anyone on the kbuild list remember where this mock-up was? I haven't been able to find anything from searches (besides this thread itself), and getting some ideas on how to approach it would be nice. The way the .config file gets magically reloaded seems like solving this could be very weird. Thanks, -Kees -- Kees Cook Pixel Security -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
