On Thu, Sep 27, 2018 at 03:17:41PM -0700, Nick Desaulniers wrote: > That's another case that I look at and wonder "why does this exist?" > The _SETUP guard exists in only one place: > $ grep -rP 'ifdef\s+_SETUP' > arch/x86/boot/cpucheck.c:#ifdef _SETUP > > which is already under arch/x86/boot/. arch/x86/boot/Makefile > unconditionally sets -D_SETUP, so what/who are we guarding against? > Looks like a guard that's ALWAYS true (and thus could be removed).
Looks like cpucheck.c was used somewhere else before and that guard was for when it is being built in arch/x86/boot/... Also, hpa says the override is because some 64-bit flags fail the 32-bit compile: https://lkml.kernel.org/r/56442061-7f55-878d-5b26-7cdd14e90...@zytor.com > Or, or... we don't redefine KBUILD_CFLAGS in arch/x86/boot/Makefile > (or any Makefile other than the top level one), and simply filter out > the flags we DONT want, a la: > > drivers/firmware/efi/libstub/Makefile: > 16 cflags-$(CONFIG_ARM64) := $(subst -pg,,$(KBUILD_CFLAGS)) ... > > ie, using Make's subst function to copy KBUILD_CFLAGS, filter out > results, then use that for cflags-y. > https://www.gnu.org/software/make/manual/html_node/Text-Functions.html Hmm, definitely sounds like an interesting idea to try... > I'm curious to know Masahiro's thoughts on this? I can't help but > shake the feeling that reassigning KBUILD_CFLAGS should be considered > an anti-pattern and warned from checkpatch.pl. For the reasons > enumerated above AND in v1: > https://lore.kernel.org/lkml/CAKwvOdmLSVH7EVGY1ExU1Fh_hvL=fuzhq-80sndfz+qhct2...@mail.gmail.com/ > (though there may be additional context from hpa answering > https://lore.kernel.org/lkml/20180926090841.gc5...@zn.tnic/). > > Relying on the compiler's default/implicit C standard (which changed > in gcc 5) for parts of the kernel but not others I feel like should be > a big red flag. I sure see your point. But then there's also the opposing argument where having stuff leak from kernel proper into .../boot/ is simply breaking the build. But then we have headers including stuff from kernel proper so I guess *that* last fact kinda wants us to not redefine KBUILD_CFLAGS ... Oh boy. > Shall I prototype up what such a change might look like (not > reassigning KBUILD_CFLAGS in arch/x86/boot/Makefile)? Maybe it's > harder/uglier than I imagine? Sounds to me like a good thing to try. If anything, we'll know more whether it makes sense at all. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
