Jérôme Carretero <
cJ-gentoo@zougloub.eu> writes:
Hi Sam,
Hi,
Slight nit-picking, but while:
commit 3fe617ccafd6f5bb33c2391d6f4eeb41c1fd0151
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2021-09-05 11:24:05 -0700
Enable '-Werror' by default for all kernel builds
did provide that WERROR=0 option...
I'm not really sure that's a nit-pick per se, rather just some
additional context. I didn't intend to claim that it covers everything ;)
... there are still parts in Linux where somehow that makefile option
isn't used, and -Werror is hardcoded, eg:
- tools/bpf/resolve_btfids/Makefile
- tools/build/Build.include
- tools/lib/bpf/Makefile
- tools/objtool/Makefile
Sure. I don't see it in some of those locations, though.
So these portions may still break on compiler update (and probably did
in the past, because somehow I have diffs for them in my kernel stash).
Yes, we should either patch these out or add -Wno-error to one of the
*FLAGS vars and hope it gets propagated everywhere but I doubt it will
be, as I had a similar issue when trying to force C11, so the former is
likely a better idea.
(But none of this means we shouldn't set WERROR=0.)
... also, maybe for QA reasons it would make sense not to do WERROR=0
when considering stabilization of kernel and/or toolchain?
I think if we were to consider that, it would be a general topic, not
really specific to the kernel. I've thought about it a few times
recently as it can sometimes be interesting to investigate why a new
warning appeared and such, but it would be a departure from existing
policy, and I don't see much reason to treat the kernel specially here.
(Especially as e.g. kernel upstream have various bots and things that
report problems like that already.)
If we were to do such a thing, it'd be the kind of thing we'd override
locally instead (and ideally have some record of upstreams where they
try to use -Werror to not be overwhelmed with results on things where
they were never -Werror clean).
So, all in all: yes, we could do with handling more locations, possibly
by patching, but I don't see that as an issue with the patch.
thanks,
sam
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)