[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f5c2d237-1cc7-5a78-c87c-29b7db825f68@urlichs.de>
Date: Sun, 13 Dec 2020 16:37:35 +0100
From: Matthias Urlichs <matthias@...ichs.de>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
Greg KH <gregkh@...uxfoundation.org>
Cc: Guenter Roeck <linux@...ck-us.net>,
Masahiro Yamada <masahiroy@...nel.org>,
"Jason A . Donenfeld" <Jason@...c4.com>,
Nathan Chancellor <natechancellor@...il.com>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Shuah Khan <shuah@...nel.org>,
clang-built-linux <clang-built-linux@...glegroups.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@...r.kernel.org>,
Network Development <netdev@...r.kernel.org>,
wireguard@...ts.zx2c4.com
Subject: Re: [PATCH v3] Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK
Miguel Ojeda wrote:
> I think we can fix them as they come.
If your change to a function breaks its callers, it's your job to fix
the callers proactively instead of waiting for "as they come" bug
reports. (Assuming, of course, that you know about the breakage. Which
you do when you tell us that the bad pattern can simply be grepped for.)
If nothing else, that's far more efficient than [number_of_callers]
separate patches by other people who each need to find the offending
change, figure out what to change and/or who to report the problem to,
and so on until the fix lands in the kernel.
Moreover, this wouldn't leave the kernel sources in a non-bisect-able
state during that time.
--
-- Matthias Urlichs
Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)
Powered by blists - more mailing lists