Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: > On Wed, Oct 9, 2024 at 12:39 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: >> >> Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> writes: >> >> > On Tue, Oct 8, 2024 at 3:35 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: >> >> >> >> The selftests build two kernel modules (bpf_testmod.ko and >> >> bpf_test_no_cfi.ko) which use copy-pasted Makefile targets. This is a >> >> bit messy, and doesn't scale so well when we add more modules, so let's >> >> consolidate these rules into a single rule generated for each module >> >> name, and move the module sources into a single directory. >> >> >> >> To avoid parallel builds of the different modules stepping on each >> >> other's toes during the 'modpost' phase of the Kbuild 'make modules', we >> >> create a single target for all the defined modules, which contains the >> >> recursive 'make' call into the modules directory. The Makefile in the >> >> subdirectory building the modules is modified to also touch a >> >> 'modules.built' file, which we can add as a dependency on the top-level >> >> selftests Makefile, thus ensuring that the modules are always rebuilt if >> >> any of the dependencies in the selftests change. >> > >> > Nice cleanup, but looks unrelated to the fix and hence >> > not a bpf material. >> > Why combine them? >> >> Because the selftest adds two more kernel modules to the selftest build, >> so we'd have to add two more directories with a single module in each >> and copy-pasted Makefile rules. It seemed simpler to just refactor the >> build of the two existing modules first, after which adding the two new >> modules means just dropping two more source files into the modules >> directory. >> >> I guess we could technically do the single-directory-per-module, and >> then send this patch as a follow-up once bpf gets merged back into >> bpf-next, but it seems a bit of a hassle, TBH. WDYT? > > The way it is right it's certainly not going into bpf tree. > So if you don't want to split then the whole thing is bpf-next then. ACK. Will see how cumbersome it is to split, and otherwise resubmit the whole thing against bpf-next. -Toke