I hope you are doing great?
This is Felix from Toronto-Canada. I have a lucrative business
offer that will benefit us both immensely within a very short
period of time. However, I need your initial approval of interest
prior to further and complete details regarding the deal.
Thanks,
Felix.
Selftests "config" file is intended to represent the config required
to run the tests; a few values are missing for the BPF selftests
and these can result in test failures due to missing helpers etc.
Add the missing values as they will help document the config needed
for a clean BPF selftests run.
Alan Maguire (2):
selftests/bpf: CONFIG_IPV6_SEG6_BPF required for test_seg6_loop.o
selftests/bpf: CONFIG_LIRC required for test_lirc_mode2.sh
tools/testing/selftests/bpf/config | 2 ++
1 file changed, 2 insertions(+)
--
1.8.3.1
Getting a clean BPF selftests run involves ensuring latest trunk LLVM/clang
are used, pahole is recent (>=1.16) and config matches the specified
config file as closely as possible. Add to bpf_devel_QA.rst and point
tools/testing/selftests/bpf/README.rst to it.
Signed-off-by: Alan Maguire <alan.maguire(a)oracle.com>
Acked-by: Andrii Nakryiko <andriin(a)fb.com>
---
Documentation/bpf/bpf_devel_QA.rst | 15 +++++++++++++++
tools/testing/selftests/bpf/README.rst | 2 ++
2 files changed, 17 insertions(+)
diff --git a/Documentation/bpf/bpf_devel_QA.rst b/Documentation/bpf/bpf_devel_QA.rst
index 38c15c6..0b3db91 100644
--- a/Documentation/bpf/bpf_devel_QA.rst
+++ b/Documentation/bpf/bpf_devel_QA.rst
@@ -437,6 +437,21 @@ needed::
See the kernels selftest `Documentation/dev-tools/kselftest.rst`_
document for further documentation.
+To maximize the number of tests passing, the .config of the kernel
+under test should match the config file fragment in
+tools/testing/selftests/bpf as closely as possible.
+
+Finally to ensure support for latest BPF Type Format features -
+discussed in `Documentation/bpf/btf.rst`_ - pahole version 1.16
+is required for kernels built with CONFIG_DEBUG_INFO_BTF=y.
+pahole is delivered in the dwarves package or can be built
+from source at
+
+https://github.com/acmel/dwarves
+
+Some distros have pahole version 1.16 packaged already, e.g.
+Fedora, Gentoo.
+
Q: Which BPF kernel selftests version should I run my kernel against?
---------------------------------------------------------------------
A: If you run a kernel ``xyz``, then always run the BPF kernel selftests
diff --git a/tools/testing/selftests/bpf/README.rst b/tools/testing/selftests/bpf/README.rst
index 0f67f1b..e885d35 100644
--- a/tools/testing/selftests/bpf/README.rst
+++ b/tools/testing/selftests/bpf/README.rst
@@ -1,6 +1,8 @@
==================
BPF Selftest Notes
==================
+General instructions on running selftests can be found in
+`Documentation/bpf/bpf_devel_QA.rst`_.
Additional information about selftest failures are
documented here.
--
1.8.3.1
Fix warnings at 'make htmldocs', and formatting issues in the resulting
documentation.
- test.h: Fix annotation in kernel-doc parameter description.
- Documentation/*.rst: Fixing formatting issues, and a duplicate label
issue due to usage of sphinx.ext.autosectionlabel and identical labels
within one document (sphinx warning)
Signed-off-by: Lothar Rubusch <l.rubusch(a)gmail.com>
---
v2: Several documentation fixes
v3: Do not touch API documentation index
v4: Replace macro argument in test.h by named variadic argument
v5: Patch format fixed
NB: checkpatch.pl will complain about flow control statements (i.e. usage
of "return") within the macro kunit_test_suites(suites_list...).
Better? I feel I'm making you a lot of extra work. I'm really sorry for
all this fuzz!
Documentation/dev-tools/kunit/start.rst | 13 ++++++++-----
Documentation/dev-tools/kunit/usage.rst | 4 ++--
include/kunit/test.h | 12 ++++++------
3 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst
index e1c5ce80ce12..bb112cf70624 100644
--- a/Documentation/dev-tools/kunit/start.rst
+++ b/Documentation/dev-tools/kunit/start.rst
@@ -32,15 +32,17 @@ test targets as well. The ``.kunitconfig`` should also contain any other config
options required by the tests.
A good starting point for a ``.kunitconfig`` is the KUnit defconfig:
+
.. code-block:: bash
cd $PATH_TO_LINUX_REPO
cp arch/um/configs/kunit_defconfig .kunitconfig
You can then add any other Kconfig options you wish, e.g.:
+
.. code-block:: none
- CONFIG_LIST_KUNIT_TEST=y
+ CONFIG_LIST_KUNIT_TEST=y
:doc:`kunit_tool <kunit-tool>` will ensure that all config options set in
``.kunitconfig`` are set in the kernel ``.config`` before running the tests.
@@ -54,8 +56,8 @@ using.
other tools (such as make menuconfig) to adjust other config options.
-Running the tests
------------------
+Running the tests (KUnit Wrapper)
+---------------------------------
To make sure that everything is set up correctly, simply invoke the Python
wrapper from your kernel repo:
@@ -105,8 +107,9 @@ have config options ending in ``_KUNIT_TEST``.
KUnit and KUnit tests can be compiled as modules: in this case the tests in a
module will be run when the module is loaded.
-Running the tests
------------------
+
+Running the tests (w/o KUnit Wrapper)
+-------------------------------------
Build and run your kernel as usual. Test output will be written to the kernel
log in `TAP <https://testanything.org/>`_ format.
diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst
index 473a2361ec37..3c3fe8b5fecc 100644
--- a/Documentation/dev-tools/kunit/usage.rst
+++ b/Documentation/dev-tools/kunit/usage.rst
@@ -595,7 +595,7 @@ able to run one test case per invocation.
KUnit debugfs representation
============================
When kunit test suites are initialized, they create an associated directory
-in /sys/kernel/debug/kunit/<test-suite>. The directory contains one file
+in ``/sys/kernel/debug/kunit/<test-suite>``. The directory contains one file
- results: "cat results" displays results of each test case and the results
of the entire suite for the last test run.
@@ -604,4 +604,4 @@ The debugfs representation is primarily of use when kunit test suites are
run in a native environment, either as modules or builtin. Having a way
to display results like this is valuable as otherwise results can be
intermixed with other events in dmesg output. The maximum size of each
-results file is KUNIT_LOG_SIZE bytes (defined in include/kunit/test.h).
+results file is KUNIT_LOG_SIZE bytes (defined in ``include/kunit/test.h``).
diff --git a/include/kunit/test.h b/include/kunit/test.h
index 9b0c46a6ca1f..47e61e1d5337 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -175,7 +175,7 @@ struct kunit_suite {
void (*exit)(struct kunit *test);
struct kunit_case *test_cases;
- /* private - internal use only */
+ /* private: internal use only */
struct dentry *debugfs;
char *log;
};
@@ -232,12 +232,12 @@ void __kunit_test_suites_exit(struct kunit_suite **suites);
* kunit_test_suites() - used to register one or more &struct kunit_suite
* with KUnit.
*
- * @suites: a statically allocated list of &struct kunit_suite.
+ * @suites_list...: a statically allocated list of &struct kunit_suite.
*
- * Registers @suites with the test framework. See &struct kunit_suite for
+ * Registers @suites_list with the test framework. See &struct kunit_suite for
* more information.
*
- * When builtin, KUnit tests are all run as late_initcalls; this means
+ * When builtin, KUnit tests are all run as late_initcalls; this means
* that they cannot test anything where tests must run at a different init
* phase. One significant restriction resulting from this is that KUnit
* cannot reliably test anything that is initialize in the late_init phase;
@@ -253,8 +253,8 @@ void __kunit_test_suites_exit(struct kunit_suite **suites);
* tests from the same place, and at the very least to do so after
* everything else is definitely initialized.
*/
-#define kunit_test_suites(...) \
- static struct kunit_suite *suites[] = { __VA_ARGS__, NULL}; \
+#define kunit_test_suites(suites_list...) \
+ static struct kunit_suite *suites[] = {suites_list, NULL}; \
static int kunit_test_suites_init(void) \
{ \
return __kunit_test_suites_init(suites); \
--
2.20.1
