| Message ID | 20221017231948.1246272-1-deso@posteo.net (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | BPF |
| Headers | show |
| Series | [bpf-next] bpf/docs: Summarize CI system and deny lists | expand |
On Mon, Oct 17, 2022 at 11:19:48PM +0000, Daniel Müller wrote: Hi Daniel, > This change adds a brief summary of the BPF continuous integration (CI) > to the BPF selftest documentation. The summary focuses not so much on > actual workings of the CI, as it is maintained outside of the > repository, but aims to document the few bits of it that are sourced > from this repisitory and that developers may want to adjust as part of s/repisitory/repository > patch submissions: the BPF kernel configuration and the deny list > file(s). > > Signed-off-by: Daniel Müller <deso@posteo.net> > --- > tools/testing/selftests/bpf/README.rst | 42 +++++++++++++++++++++++++- > 1 file changed, 41 insertions(+), 1 deletion(-) > > diff --git a/tools/testing/selftests/bpf/README.rst b/tools/testing/selftests/bpf/README.rst > index d3c6b3d..d1d7e9 100644 > --- a/tools/testing/selftests/bpf/README.rst > +++ b/tools/testing/selftests/bpf/README.rst > @@ -6,13 +6,53 @@ General instructions on running selftests can be found in > > __ /Documentation/bpf/bpf_devel_QA.rst#q-how-to-run-bpf-selftests > > +============= > +BPF CI System > +============= > + > +BPF employs a continuous integration (CI) system to check patch submission in an > +automated fashion. The system runs selftests for each patch in a series. Results > +are propagated to patchwork, where failures are highlighted similar to > +violations of other checks (such as additional warnings being emitted or a > +``scripts/checkpatch.pl`` reported deficiency): > + > + https://patchwork.kernel.org/project/netdevbpf/list/?delegate=121173 > + > +The CI system executes tests on multiple architectures. It uses a kernel > +configuration derived from both the generic and architecture specific config > +file fragments below ``tools/testing/selftests/bpf/`` (e.g., ``config`` and > +``config.x86_64``). > + > +Denylisting Tests > +================= > + > +It is possible for some architectures to not have support for all BPF features. > +In such a case tests in CI may fail. An example of such a shortcoming is BPF > +trampoline support on IBM's s390 architecture. For cases like this, an in-tree tiny nit: Elsewhere in the README we're saying s390x. Should we just say the same here for consistency? Looks good otherwise, thanks. Acked-by: David Vernet <void@manifault.com>
diff --git a/tools/testing/selftests/bpf/README.rst b/tools/testing/selftests/bpf/README.rst index d3c6b3d..d1d7e9 100644 --- a/tools/testing/selftests/bpf/README.rst +++ b/tools/testing/selftests/bpf/README.rst @@ -6,13 +6,53 @@ General instructions on running selftests can be found in __ /Documentation/bpf/bpf_devel_QA.rst#q-how-to-run-bpf-selftests +============= +BPF CI System +============= + +BPF employs a continuous integration (CI) system to check patch submission in an +automated fashion. The system runs selftests for each patch in a series. Results +are propagated to patchwork, where failures are highlighted similar to +violations of other checks (such as additional warnings being emitted or a +``scripts/checkpatch.pl`` reported deficiency): + + https://patchwork.kernel.org/project/netdevbpf/list/?delegate=121173 + +The CI system executes tests on multiple architectures. It uses a kernel +configuration derived from both the generic and architecture specific config +file fragments below ``tools/testing/selftests/bpf/`` (e.g., ``config`` and +``config.x86_64``). + +Denylisting Tests +================= + +It is possible for some architectures to not have support for all BPF features. +In such a case tests in CI may fail. An example of such a shortcoming is BPF +trampoline support on IBM's s390 architecture. For cases like this, an in-tree +deny list file, located at ``tools/testing/selftests/bpf/DENYLIST.<arch>``, can +be used to prevent the test from running on such an architecture. + +In addition to that, the generic ``tools/testing/selftests/bpf/DENYLIST`` is +honored on every architecture running tests. + +These files are organized in three columns. The first column lists the test in +question. This can be the name of a test suite or of an individual test. The +remaining two columns provide additional meta data that helps identify and +classify the entry: column two is a copy and paste of the error being reported +when running the test in the setting in question. The third column, if +available, summarizes the underlying problem. A value of ``trampoline``, for +example, indicates that lack of trampoline support is causing the test to fail. +This last entry helps identify tests that can be re-enabled once such support is +added. + ========================= Running Selftests in a VM ========================= It's now possible to run the selftests using ``tools/testing/selftests/bpf/vmtest.sh``. The script tries to ensure that the tests are run with the same environment as they -would be run post-submit in the CI used by the Maintainers. +would be run post-submit in the CI used by the Maintainers, with the exception +that deny lists are not automatically honored. This script downloads a suitable Kconfig and VM userspace image from the system used by the CI. It builds the kernel (without overwriting your existing Kconfig), recompiles the
This change adds a brief summary of the BPF continuous integration (CI) to the BPF selftest documentation. The summary focuses not so much on actual workings of the CI, as it is maintained outside of the repository, but aims to document the few bits of it that are sourced from this repisitory and that developers may want to adjust as part of patch submissions: the BPF kernel configuration and the deny list file(s). Signed-off-by: Daniel Müller <deso@posteo.net> --- tools/testing/selftests/bpf/README.rst | 42 +++++++++++++++++++++++++- 1 file changed, 41 insertions(+), 1 deletion(-)