Re: [PATCH bpf 2/4] selftests/bpf: Consolidate kernel modules into common directory

["Toke Høiland-Jørgensen" <toke@redhat.com>]

Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:

> On Wed, Oct 9, 2024 at 12:39 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
>>
>> > On Tue, Oct 8, 2024 at 3:35 AM Toke Høiland-Jørgensen <toke@redhat.com> 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