> diff --git a/tools/testing/selftests/sched_ext/Makefile > b/tools/testing/selftests/sched_ext/Makefile > index 3cfe90e0f34f..dd3f5594af24 100644 > --- a/tools/testing/selftests/sched_ext/Makefile > +++ b/tools/testing/selftests/sched_ext/Makefile > @@ -14,48 +14,29 @@ CURDIR := $(abspath .) > REPOROOT := $(abspath ../../../..) > TOOLSDIR := $(REPOROOT)/tools > LIBDIR := $(TOOLSDIR)/lib > -BPFDIR := $(LIBDIR)/bpf > TOOLSINCDIR := $(TOOLSDIR)/include > -BPFTOOLDIR := $(TOOLSDIR)/bpf/bpftool > -APIDIR := $(TOOLSINCDIR)/uapi > GENDIR := $(REPOROOT)/include/generated > GENHDR := $(GENDIR)/autoconf.h > -SCXTOOLSDIR := $(TOOLSDIR)/sched_ext > SCXTOOLSINCDIR := $(TOOLSDIR)/sched_ext/include > > -OUTPUT_DIR := $(OUTPUT)/build > -OBJ_DIR := $(OUTPUT_DIR)/obj > -INCLUDE_DIR := $(OUTPUT_DIR)/include > -BPFOBJ_DIR := $(OBJ_DIR)/libbpf > -SCXOBJ_DIR := $(OBJ_DIR)/sched_ext > -BPFOBJ := $(BPFOBJ_DIR)/libbpf.a > -LIBBPF_OUTPUT := $(OBJ_DIR)/libbpf/libbpf.a > - > -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/ > - > -VMLINUX_BTF_PATHS ?= $(if $(O),$(O)/vmlinux) > \ > - $(if $(KBUILD_OUTPUT),$(KBUILD_OUTPUT)/vmlinux) > \ > - ../../../../vmlinux > \ > - /sys/kernel/btf/vmlinux > \ > - /boot/vmlinux-$(shell uname -r) > -VMLINUX_BTF ?= $(abspath $(firstword $(wildcard $(VMLINUX_BTF_PATHS)))) > -ifeq ($(VMLINUX_BTF),) > -$(error Cannot find a vmlinux for VMLINUX_BTF at any of > "$(VMLINUX_BTF_PATHS)") > -endif > +# Build scheduler skeletons and subskeletons with the shared BPF rules. > +BPF_SRCS := $(wildcard *.bpf.c) > +BPF_SKEL_EXT := .bpf.skel.h > +BPF_GEN_SUBSKEL := 1
This isn't a bug, but is anything consuming the generated *.bpf.subskel.h headers? Grepping the directory for "subskel" matches only the Makefile itself - no .c or .h file under tools/testing/selftests/sched_ext/ includes a subskeleton header. The pre-patch rule generated them too, so this preserves existing behavior, but the conversion makes the subskeleton an explicit one-line opt-in. Would dropping BPF_GEN_SUBSKEL be a reasonable follow-up to save a bpftool run per scheduler? > +# Preserve the existing build/ layout. > +BPF_OBJ_DIR := $(OUTPUT)/build/obj/sched_ext > +BPF_SKEL_DIR := $(OUTPUT)/build/include > +SCXOBJ_DIR := $(BPF_OBJ_DIR) > > -BPFTOOL ?= $(DEFAULT_BPFTOOL) > +include ../lib.bpf.mk [ ... ] > @@ -64,102 +45,26 @@ endif > > LDFLAGS = -lelf -lz -lpthread -lzstd [ ... ] > +EXTRA_CLEAN += $(OUTPUT)/build > > ################ > # C schedulers # > ################ > > -override define CLEAN > - rm -rf $(OUTPUT_DIR) > - rm -f $(TEST_GEN_PROGS) > -endef > - > -# Every testcase takes all of the BPF progs are dependencies by default. This > -# allows testcases to load any BPF scheduler, which is useful for testcases > -# that don't need their own prog to run their test. > -all_test_bpfprogs := $(foreach prog,$(wildcard > *.bpf.c),$(INCLUDE_DIR)/$(patsubst %.c,%.skel.h,$(prog))) > +# Build every scheduler before each test. > +all_test_bpfprogs := $(BPF_SKELS) This isn't a bug, but since the variable assignment is otherwise a straight substitution (the foreach expression becomes $(BPF_SKELS)), would it be worth keeping the original comment wording? The previous text explained the rationale - "Every testcase takes all of the BPF progs as dependencies by default. This allows testcases to load any BPF scheduler, which is useful for testcases that don't need their own prog to run their test." - while the replacement restates what the following line does and drops the reason a testcase depends on schedulers it does not own. --- AI reviewed your patch. Please fix the bug or email reply why it's not a bug. See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md CI run summary: https://github.com/kernel-patches/bpf/actions/runs/34573210499
