[bpf-next,v2,0/3] Maintain selftest configuration in-tree

Message

Daniel Müller July 19, 2022, 6:02 p.m. UTC

BPF selftests mandate certain kernel configuration options to be present in
order to pass. Currently the "reference" config files containing these options
are hosted in a separate repository [0]. From there they are picked up by the
BPF continuous integration system as well as the in-tree vmtest.sh helper
script, which allows for running tests in a VM-based setup locally.

But it gets worse, as "BPF CI" is really two CI systems: one for libbpf
(mentioned above) and one for the bpf-next kernel repository (or more precisely:
family of repositories, as bpf-rc is using the system). As such, we have an
additional -- and slightly divergent -- copy of these configurations.

This patch set proposes the merging of said configurations into this repository.
Doing so provides several benefits:
1) the vmtest.sh script is now self-contained, no longer requiring to pull
   configurations over the network
2) we can have a single copy of these configurations, eliminating the
   maintenance burden of keeping two versions in-sync
3) the kernel tree is the place where most development happens, so it is the
   most natural to adjust configurations as changes are proposed there, as
   opposed to out-of-tree, where they would always remain an afterthought

The patch set is structed in such a way that we first integrate the external
configuration [0] and then adjust the vmtest.sh script to pick up the local
configuration instead of reaching out to GitHub.

[0] https://github.com/libbpf/libbpf/tree/20f03302350a4143825cedcbd210c4d7112c1898/travis-ci/vmtest/configs

---
Changelog:
v1 -> v2:
- minimized imported kernel configs and made them build on top of existing
  tools/testing/selftests/bpf/config
  - moved them directly into tools/testing/selftests/bpf/
- sorted and cleaned up tools/testing/selftests/bpf/config
- removed "selftests/bpf: Integrate vmtest configs" from patch set
- removed 4.9 & 5.5 configs

Daniel Müller (3):
  selftests/bpf: Sort configuration
  selftests/bpf: Copy over libbpf configs
  selftests/bpf: Adjust vmtest.sh to use local kernel configuration

 tools/testing/selftests/bpf/DENYLIST       |   6 +
 tools/testing/selftests/bpf/DENYLIST.s390x |  67 ++++++
 tools/testing/selftests/bpf/config         | 101 ++++-----
 tools/testing/selftests/bpf/config.s390x   | 154 +++++++++++++
 tools/testing/selftests/bpf/config.x86_64  | 251 +++++++++++++++++++++
 tools/testing/selftests/bpf/vmtest.sh      |  51 +++--
 6 files changed, 561 insertions(+), 69 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/DENYLIST
 create mode 100644 tools/testing/selftests/bpf/DENYLIST.s390x
 create mode 100644 tools/testing/selftests/bpf/config.s390x
 create mode 100644 tools/testing/selftests/bpf/config.x86_64

Comments

Martin KaFai Lau July 22, 2022, 6:15 a.m. UTC | #1

On Tue, Jul 19, 2022 at 06:02:48PM +0000, Daniel Müller wrote:
> BPF selftests mandate certain kernel configuration options to be present in
> order to pass. Currently the "reference" config files containing these options
> are hosted in a separate repository [0]. From there they are picked up by the
> BPF continuous integration system as well as the in-tree vmtest.sh helper
> script, which allows for running tests in a VM-based setup locally.
> 
> But it gets worse, as "BPF CI" is really two CI systems: one for libbpf
> (mentioned above) and one for the bpf-next kernel repository (or more precisely:
> family of repositories, as bpf-rc is using the system). As such, we have an
> additional -- and slightly divergent -- copy of these configurations.
> 
> This patch set proposes the merging of said configurations into this repository.
> Doing so provides several benefits:
> 1) the vmtest.sh script is now self-contained, no longer requiring to pull
>    configurations over the network
> 2) we can have a single copy of these configurations, eliminating the
>    maintenance burden of keeping two versions in-sync
> 3) the kernel tree is the place where most development happens, so it is the
>    most natural to adjust configurations as changes are proposed there, as
>    opposed to out-of-tree, where they would always remain an afterthought
> 
> The patch set is structed in such a way that we first integrate the external
> configuration [0] and then adjust the vmtest.sh script to pick up the local
> configuration instead of reaching out to GitHub.
Acked-by: Martin KaFai Lau <[e-mail]>