On 8/18/25 1:16 PM, Kevin Brodsky wrote:
On 31/07/2025 18:01, Muhammad Usama Anjum wrote:
[...]
diff --git a/tools/testing/selftests/mm/Makefile b/tools/testing/selftests/mm/Makefile index 23d4bf6215465..d75f1effcb791 100644 --- a/tools/testing/selftests/mm/Makefile +++ b/tools/testing/selftests/mm/Makefile @@ -20,7 +20,6 @@ endif # thus tricking Make (and you!) into believing that All Is Well, in subsequent # make invocations: .DELETE_ON_ERROR:
# Avoid accidental wrong builds, due to built-in rules working just a little # bit too well--but not quite as well as required for our situation here. # @@ -35,6 +34,7 @@ MAKEFLAGS += --no-builtin-rules CFLAGS = -Wall -O2 -I $(top_srcdir) $(EXTRA_CFLAGS) $(KHDR_INCLUDES) $(TOOLS_INCLUDES) CFLAGS += -Wunreachable-code +CFLAGS += -Wunused -Wunused-parameter -Wunused-function -Wunused-label -Wunused-variable -Wunused-value
-Wall implies all of these except -Wunused-parameter (at least according to gcc(1)).
I'll remove others in separate patch.
As to -Wunused-parameter I am frankly not convinced it's worth the hassle. We're getting 90 lines changed in patch 6-8 just to mark parameters as unused, in other words noise to keep the compiler happy. It is not enabled by default in the kernel proper precisely because it is so noisy when callbacks are involved.
Patch 5 is clearly an improvement, but I'd rather take it without actually enabling -Wunused-parameter. The rest of this patch isn't that useful either IMHO.
Patch 5 removes genuinely unused parameters flagged by the compiler. If we drop the -Wunused-parameter option, however, new unused parameters will continue to creep in with future patches. The goal of enabling this warning is to surface such issues early so developers can address them during development, rather than later during review or debugging.
Long term, I’d like us to rely more on compiler and static analysis just like kernel to catch these kinds of problems proactively, instead of waiting until they’re reported or someone fixes them later. While it may feel like noise initially, this is largely a one-time cleanup—once done, developers will simply fix warnings as they arise, keeping the codebase cleaner going forward.
- Kevin