On 2026-10-11 19:36:43-0400, Sasha Levin wrote:
> Add a "Kernel selftests" sub-menu with one entry per selftests directory
> that builds with only a C library and does not write into the source
> tree. Each is built as "make kselftest-all" builds it, with KHDR_INCLUDES
> pointing at the UAPI headers installed in the object tree, but by its own
> make, so the selected ones build in parallel. Selftests whose Makefile
> does not use KHDR_INCLUDES still build against the C library's copy of
> the UAPI headers.
> 
> The selftests do not track header dependencies, so a selftest is built
> again from scratch when its own directory, a header or makefile any
> selftest may share, or a kernel source it includes directly (the vDSO
> test includes the architecture's vDSO code) is newer than its last
> build.
> 
> Selftests that need libraries beyond the C library, a vmlinux with BTF,
> or a sanitizer runtime are left out for now.
> 
> Assisted-by: LLM
> Signed-off-by: Sasha Levin <[email protected]>
> ---
>  tools/Kconfig         | 239 ++++++++++++++++++++++++++++++++++++++++++
>  tools/Makefile.kbuild | 100 ++++++++++++++++++
>  2 files changed, 339 insertions(+)

(...)

> diff --git a/tools/Makefile.kbuild b/tools/Makefile.kbuild
> index 62fd494253eca..c31347258d0a9 100644
> --- a/tools/Makefile.kbuild
> +++ b/tools/Makefile.kbuild
> @@ -92,6 +92,106 @@ PHONY += perf
>  perf: FORCE
>       $(call build,$(outdir)/perf,-C $(toolsdir)/perf -f Makefile.perf 
> O=$(outdir)/perf $(perf-flags) $(perf-flags-y),,TOOLS_BUILD_PERF)

(...)

> +# Unlike tools/build, the selftests do not track header dependencies. A
> +# selftest is built again from scratch when its own directory, a header or
> +# makefile any selftest may share, or a kernel source it includes directly
> +# is newer than its last build.
> +selftest-shared := $(outdir)/selftests/.shared
> +selftest-extra-vDSO := $(abs_srctree)/arch/$(SRCARCH)

Can we not fix the selftests to properly track header dependencies?
That has been an annoyance of mine for quite some time.
It would also get rid of a whole bunch of hackery here.

(...)

Reply via email to