Re: [PATCH v2] selftests: sched_ext: Add sched_ext as proper selftest target

["Björn Töpel" <bjorn@kernel.org>]

Mark Brown <broonie@kernel.org> writes:

> On Mon, Oct 07, 2024 at 09:31:32AM +0200, Björn Töpel wrote:
>
>> When building the kselftest suite, e.g.:
>
>>   make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- \
>>     SKIP_TARGETS="" O=/output/foo -C tools/testing/selftests install
>
>> The expectation is that the sched_ext is included, cross-built, and
>> placed into /output/foo.
>
> When building for arm64 with this applied on top of mainline or -next
> I'm seeing:

Thanks for taking it for a spin!

>    make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -C tools/testing/selftests TARGETS=sched_ext SKIP_TARGETS="
>
> give
>
>   CLNG-BPF create_dsq.bpf.o
> In file included from create_dsq.bpf.c:9:
> /home/broonie/git/linux/tools/sched_ext/include/scx/common.bpf.h:33:17: error: use of undeclared identifier 'SCX_DSQ_FLAG_BUILTIN'
>    33 |         _Static_assert(SCX_DSQ_FLAG_BUILTIN,
>       |                        ^

This is most likely due to incorrect VMLINUX_BTF_PATHS, so that
vmlinux.h is incorrectly generated. Try grepping for
SCX_DSQ_FLAG_BUILTIN in vmlinux.h.

> and more (my system clang is clang 20).  It's also failing with a native
> x86_64 build in the same way.  I've run "make headers_install", it looks
> like clang is not getting told about the copy of the headers installed
> in ./usr/include:
>
> clang -g -D__TARGET_ARCH_x86 -mlittle-endian -I/home/broonie/git/linux/tools/testing/selftests/sched_ext/include -I/home/broonie/git/linux/tools/testing/selftests/sched_ext/include/bpf-compat -I/home/broonie/git/linux/tools/testing/selftests/sched_ext/build/include -I/home/broonie/git/linux/tools/include/uapi -I/home/broonie/git/linux/tools/sched_ext/include -I/home/broonie/git/linux/include -idirafter /usr/lib/llvm-20/lib/clang/20/include -idirafter /usr/local/include -idirafter /usr/include/x86_64-linux-gnu -idirafter /usr/include  -Wall -Wno-compare-distinct-pointer-types -Wno-incompatible-function-pointer-types -O2 -mcpu=v3 -target bpf -c create_dsq.bpf.c -o /home/broonie/git/linux/tools/testing/selftests/sched_ext/build/obj/sched_ext/create_dsq.bpf.o

The sched_ext BPF programs relies on a vmlinux.h, which is generated
using bpftool and the vmlinux with BTF information. Have you built a
kernel with BTF support?

>> Add CROSS_COMPILE, OUTPUT, and TARGETS support to the sched_ext
>> selftest. Also, remove some variables that were unused by the
>> Makefile.
>
>> +ifneq ($(CROSS_COMPILE),)
>> +DEFAULT_BPFTOOL := $(OUTPUT_DIR)/host/sbin/bpftool
>> +HOST_OBJ_DIR := $(OBJ_DIR)/host/bpftool
>> +HOST_LIBBPF_OUTPUT := $(OBJ_DIR)/host/libbpf/
>> +HOST_LIBBPF_DESTDIR := $(OUTPUT_DIR)/host/
>> +HOST_DESTDIR := $(OUTPUT_DIR)/host/
>> +else
>> +DEFAULT_BPFTOOL := $(OUTPUT_DIR)/sbin/bpftool
>> +HOST_OBJ_DIR := $(OBJ_DIR)/bpftool
>> +HOST_LIBBPF_OUTPUT := $(OBJ_DIR)/libbpf/
>> +HOST_LIBBPF_DESTDIR := $(OUTPUT_DIR)/
>> +HOST_DESTDIR := $(OUTPUT_DIR)/
>> +endif
>
> This won't detect a cross compile when building using LLVM as that
> doesn't need to set CROSS_COMPILE, it can use the same binaries for all
> targets.  There's runes in the Makefile for the mm selftests for
> identifying the target architecture, though actually I'm wondering if
> it's worth just always building the host copy and never having to worry
> if the target build is a cross build or not?  It's obvious overhead in
> the native case though if we actually need the target copy.

Yeah, that would indeed simplify things! I'll spin a v3 with that (and
wait for more feedback).


Thanks for testing the patch!
Björn

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv