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.
