From: Andrew Lunn <andrew@lunn.ch>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: netdev <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Michal Marek <michal.lkml@markovi.net>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
clang-built-linux <clang-built-linux@googlegroups.com>
Subject: Re: [PATCH RFC/RFT 0/2] W=1 by default for Ethernet PHY subsystem
Date: Sun, 20 Sep 2020 16:53:51 +0200 [thread overview]
Message-ID: <20200920145351.GB3689762@lunn.ch> (raw)
In-Reply-To: <CAK7LNASY6hTDo8cuH5H_ExciEybBPbAuB3OxsmHbUUgoES94EA@mail.gmail.com>
On Sun, Sep 20, 2020 at 12:42:51PM +0900, Masahiro Yamada wrote:
> On Sun, Sep 20, 2020 at 4:03 AM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > There is a movement to make the code base compile clean with W=1. Some
> > subsystems are already clean. In order to keep them clean, we need
> > developers to build new code with W=1 by default in these subsystems.
> >
> > This patchset refactors the core Makefile warning code to allow the
> > additional warnings W=1 adds available to any Makefile. The Ethernet
> > PHY subsystem Makefiles then make use of this to make W=1 the default
> > for this subsystem.
> >
> > RFT since i've only tested with x86 and arm with a modern gcc. Is the
> > code really clean for older compilers? For clang?
>
>
> I appreciate your efforts for keeping your subsystems
> clean for W=1 builds, and I hope this work will be
> extended towards upper directory level,
> drivers/net/phy -> drivers/net -> drivers/.
It definitely is.
drivers/net:
https://www.spinics.net/lists/netdev/msg683687.html
drivers/spi
https://www.spinics.net/lists/linux-spi/msg23280.html
drivers/mfd
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2211644.html
etc.
> So, another idea might be hard-coding extra warnings
> like drivers/gpu/drm/i915/Makefile.
>
> For example, your subsystem already achieved
> -Wmissing-declarations free.
>
> You can add
>
> subdir-ccflags-y += -Wmissing-declarations
>
> to drivers/net/phy/Makefile.
>
> Once you fix all net drivers, you can move it to
> the parent, drivers/net/Makefile.
>
> Then, drivers/Makefile next, and if it reaches
> the top directory level, we can move it to W=0.
Do you think this will scale?
Lets just assume we do this at driver/ level. We have 141
subdirectories in driver/ . So we will end up with 141
subdir-ccflags-y +=
lines which we need to maintain.
Given the current cleanup effort, many are going to be identical to
todays W=1.
How do we maintain those 141 lines when it is time to add a new flag
to W=1?
How often are new W=1 flags added? My patch exported
KBUILD_CFLAGS_WARN1. How about instead we export
KBUILD_CFLAGS_WARN1_20200920. A subsystem can then sign up to being
W=1 clean as for the 20200920 definition of W=1.
If you want to add a new warning
KBUILD_CFLAGS_WARN1_20201031 := KBUILD_CFLAGS_WARN1_20200920 + "-Wghosts"
W=1 will always use the latest. You then build with W=1, maybe by
throwing it at 0-day, find which subsystems are still clean, and
update their subdir-ccflags-y += line with the new timestamp?
This should help with scaling, in that a subsystem is not dealing with
a list of warnings, just a symbol that represents the warnings from a
particular date?
Or maybe others have better ideas?
Andrew
next prev parent reply other threads:[~2020-09-20 14:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-19 19:02 [PATCH RFC/RFT 0/2] W=1 by default for Ethernet PHY subsystem Andrew Lunn
2020-09-19 19:02 ` [PATCH RFC/RFT 1/2] scripts: Makefile.extrawarn: Add W=1 warnings to a symbol Andrew Lunn
2020-09-19 19:02 ` [PATCH RFC/RFT 2/2] net: phylib: Enable W=1 by default Andrew Lunn
2020-09-20 3:42 ` [PATCH RFC/RFT 0/2] W=1 by default for Ethernet PHY subsystem Masahiro Yamada
2020-09-20 14:53 ` Andrew Lunn [this message]
2021-02-10 18:39 ` Jason Gunthorpe
2021-02-10 18:43 ` Jakub Kicinski
2021-02-10 18:55 ` Jason Gunthorpe
2021-02-10 19:01 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200920145351.GB3689762@lunn.ch \
--to=andrew@lunn.ch \
--cc=clang-built-linux@googlegroups.com \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=michal.lkml@markovi.net \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.