On Wed, Jun 19, 2019 at 08:46:19AM -0700, James Bottomley wrote:
> On Wed, 2019-06-19 at 17:48 +0300, Laurent Pinchart wrote:

> > It's not automatic though, if it depends on a Kconfig option that is
> > disabled by default. The built bots can enable it, while users would
> > ignore it. That being said, having it as a per-tree build bot option
> > should work as well.

> I really don't think well made build bots would enable this.  The
> problem with -Werror is it's single threaded on the first problem. 
> What a generic build bot wants to do is compile the entire tree and
> then diff the output to find the additional warnings for everything.  I
> could see a tree specific build bot being more interested (until the
> build fails on an unrelated subsystem).

If you're doing build coverage you can always use make -k and still
build everything but yeah.

> > All my kernel compilation scripts use -Werror, and that does a great
> > job at catching problems. It can be a bit annoying at times when

>    1. You're going to force us to annotate all those spurious warnings
>       that we've been ignoring because gcc should get fixed; incorrectly
>       flagged uninitialized variables being the most annoying.

The next time I have to write a "this just shuts up the warning, it
doesn't even consider if there might be a real problem" mail I'm
probably going to turn it into a form letter :(

>    2. Different versions of gcc produce different warnings: so now we'll
>       eventually have to target a specific gcc version and not upgrade
>       until we're ready because newer versions come with shiny new
>       warnings.

This isn't as bad as it used to be since we have people looking at the
new compiler versions as they come down the line and trying to ensure
that things work cleanly before the compilers even get released (Arnd
does a bunch of this, I know some of the clang people are paying
attention as well).  It's something the compiler people have been
interested as part of their QA, there's no guarantee everything will be
perfect but things tend to do reasonably well these days.

A similar issue applies with older compiler versions and false
positives, people do look at that but it gets a bit less coverage.
There's infrastructure for this in KernelCI (which is currently used for
the clang/arm64 testing in production), if there were build capacity
available it'd be relatively easy in technical terms to have some
coverage there.