As warned by:
./include/kunit/test.h:504: WARNING: Block quote ends without a blank line; unexpected unindent.
The right way to describe a function is:
name - description
Instead, kunit_remove_resource was using:
name: description
Causing it to be improperly parsed.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org>
---
include/kunit/test.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/kunit/test.h b/include/kunit/test.h
index 41b3a266bf8c..5c5ed262a950 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -498,8 +498,8 @@ static inline int kunit_destroy_named_resource(struct kunit *test,
}
/**
- * kunit_remove_resource: remove resource from resource list associated with
- * test.
+ * kunit_remove_resource() - remove resource from resource list associated with
+ * test.
* @test: The test context object.
* @res: The resource to be removed.
*
--
2.26.2
There are some warnings there:
./include/kunit/test.h:90: warning: Function parameter or member 'name' not described in 'kunit_resource'
./include/kunit/test.h:353: warning: Function parameter or member 'res' not described in 'kunit_add_resource'
./include/kunit/test.h:367: warning: Function parameter or member 'res' not described in 'kunit_add_named_resource'
./include/kunit/test.h:367: warning: Function parameter or member 'name' not described in 'kunit_add_named_resource'
./include/kunit/test.h:367: warning: Function parameter or member 'data' not described in 'kunit_add_named_resource'
./include/kunit/test.h:367: warning: Excess function parameter 'name_data' description in 'kunit_add_named_resource'
Address them, ensuring that all non-private arguments will
be properly described. With that regards, at struct kunit_resource,
the free argument is described as user-provided. So, this
doesn't seem to belong to the "private" part of the struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org>
---
include/kunit/test.h | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/include/kunit/test.h b/include/kunit/test.h
index 59f3144f009a..41b3a266bf8c 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -25,6 +25,7 @@ typedef void (*kunit_resource_free_t)(struct kunit_resource *);
/**
* struct kunit_resource - represents a *test managed resource*
* @data: for the user to store arbitrary data.
+ * @name: optional name
* @free: a user supplied function to free the resource. Populated by
* kunit_resource_alloc().
*
@@ -80,10 +81,10 @@ typedef void (*kunit_resource_free_t)(struct kunit_resource *);
*/
struct kunit_resource {
void *data;
- const char *name; /* optional name */
-
- /* private: internal use only. */
+ const char *name;
kunit_resource_free_t free;
+
+ /* private: internal use only. */
struct kref refcount;
struct list_head node;
};
@@ -343,6 +344,7 @@ static inline void kunit_put_resource(struct kunit_resource *res)
* none is supplied, the resource data value is simply set to @data.
* If an init function is supplied, @data is passed to it instead.
* @free: a user-supplied function to free the resource (if needed).
+ * @res: The resource.
* @data: value to pass to init function or set in resource data field.
*/
int kunit_add_resource(struct kunit *test,
@@ -356,7 +358,9 @@ int kunit_add_resource(struct kunit *test,
* @test: The test context object.
* @init: a user-supplied function to initialize the resource data, if needed.
* @free: a user-supplied function to free the resource data, if needed.
- * @name_data: name and data to be set for resource.
+ * @res: The resource.
+ * @name: name to be set for resource.
+ * @data: value to pass to init function or set in resource data field.
*/
int kunit_add_named_resource(struct kunit *test,
kunit_resource_init_t init,
--
2.26.2
## TL;DR
This patchset adds a centralized executor to dispatch tests rather than
relying on late_initcall to schedule each test suite separately along
with a couple of new features that depend on it.
## What am I trying to do?
Conceptually, I am trying to provide a mechanism by which test suites
can be grouped together so that they can be reasoned about collectively.
The second to last patch in this series add features which depend on
this:
PATCH 04/05 Prints out a test plan[1] right before KUnit tests are run;
this is valuable because it makes it possible for a test
harness to detect whether the number of tests run matches
the number of tests expected to be run, ensuring that no
tests silently failed. The test plan includes a count of
tests that will run. With the centralized executor, the
tests are located in a single data structure and thus can be
counted.
In addition, by dispatching tests from a single location, we can
guarantee that all KUnit tests run after late_init is complete, which
was a concern during the initial KUnit patchset review (this has not
been a problem in practice, but resolving with certainty is nevertheless
desirable).
Other use cases for this exist, but the above features should provide an
idea of the value that this could provide.
## Changes since last revision:
- Renamed the KUNIT_TEST_SUITES the KUNIT_TABLE section and moved it
from INIT_DATA_SECTION to INIT_DATA; this had the additional
consequence of making the first several architecture specific patches
unnecessary - suggested by Kees.
- Dropped the kunit_shutdown patches; I think it makes more sense to
reintroduce them in a later patchset.
Alan Maguire (1):
kunit: test: create a single centralized executor for all tests
Brendan Higgins (4):
vmlinux.lds.h: add linker section for KUnit test suites
init: main: add KUnit to kernel init
kunit: test: add test plan to KUnit TAP format
Documentation: kunit: add a brief blurb about kunit_test_suite
Documentation/dev-tools/kunit/usage.rst | 5 ++
include/asm-generic/vmlinux.lds.h | 10 ++-
include/kunit/test.h | 76 +++++++++++++-----
init/main.c | 4 +
lib/kunit/Makefile | 3 +-
lib/kunit/executor.c | 43 ++++++++++
lib/kunit/test.c | 13 +--
tools/testing/kunit/kunit_parser.py | 76 ++++++++++++++----
.../test_is_test_passed-all_passed.log | Bin 1562 -> 1567 bytes
.../test_data/test_is_test_passed-crash.log | Bin 3016 -> 3021 bytes
.../test_data/test_is_test_passed-failure.log | Bin 1700 -> 1705 bytes
11 files changed, 180 insertions(+), 50 deletions(-)
create mode 100644 lib/kunit/executor.c
base-commit: 145ff1ec090dce9beb5a9590b5dc288e7bb2e65d
--
2.28.0.163.g6104cc2f0b6-goog
Good morning,
looking for companies interested in raising additional capital by diversifying their offer in soaps, liquids and gels for hand disinfection and cosmetics for body and hair care.
The distribution of innovative products corresponding to the current preferences of customers in the field of hygiene and preventive healthcare allows our partners to gain new markets and achieve better economic results.
In addition to products with bactericidal action, our range includes shower gels, shampoos and hair conditioners, as well as efficient, concentrated detergents.
The versatility (suitable for all skin types) combined with an affordable price means that customers make an informed choice of a product among others available on the market.
Are you interested in cooperation?
William Jones
The kci_test_encap_fou() test from kci_test_encap() in rtnetlink.sh
needs the fou module to work. Otherwise it will fail with:
$ ip netns exec "$testns" ip fou add port 7777 ipproto 47
RTNETLINK answers: No such file or directory
Error talking to the kernel
Add the CONFIG_NET_FOU into the config file as well. Which needs at
least to be set as a loadable module.
Signed-off-by: Po-Hsu Lin <po-hsu.lin(a)canonical.com>
---
tools/testing/selftests/net/config | 1 +
tools/testing/selftests/net/rtnetlink.sh | 6 ++++++
2 files changed, 7 insertions(+)
diff --git a/tools/testing/selftests/net/config b/tools/testing/selftests/net/config
index 3b42c06b..c5e50ab 100644
--- a/tools/testing/selftests/net/config
+++ b/tools/testing/selftests/net/config
@@ -31,3 +31,4 @@ CONFIG_NET_SCH_ETF=m
CONFIG_NET_SCH_NETEM=y
CONFIG_TEST_BLACKHOLE_DEV=m
CONFIG_KALLSYMS=y
+CONFIG_NET_FOU=m
diff --git a/tools/testing/selftests/net/rtnetlink.sh b/tools/testing/selftests/net/rtnetlink.sh
index 7c38a90..a711b3e 100755
--- a/tools/testing/selftests/net/rtnetlink.sh
+++ b/tools/testing/selftests/net/rtnetlink.sh
@@ -520,6 +520,11 @@ kci_test_encap_fou()
return $ksft_skip
fi
+ if ! /sbin/modprobe -q -n fou; then
+ echo "SKIP: module fou is not found"
+ return $ksft_skip
+ fi
+ /sbin/modprobe -q fou
ip -netns "$testns" fou add port 7777 ipproto 47 2>/dev/null
if [ $? -ne 0 ];then
echo "FAIL: can't add fou port 7777, skipping test"
@@ -540,6 +545,7 @@ kci_test_encap_fou()
return 1
fi
+ /sbin/modprobe -q -r fou
echo "PASS: fou"
}
--
2.7.4
From: SeongJae Park <sjpark(a)amazon.de>
If 'CONFIG_KUNIT=m', letting kunit tests that do not support loadable
module build depends on 'KUNIT' instead of 'KUNIT=y' result in compile
errors. This commit updates the document for this.
Fixes: 9fe124bf1b77 ("kunit: allow kunit to be loaded as a module")
Signed-off-by: SeongJae Park <sjpark(a)amazon.de>
---
Documentation/dev-tools/kunit/start.rst | 2 +-
Documentation/dev-tools/kunit/usage.rst | 5 +++++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst
index d23385e3e159..454f307813ea 100644
--- a/Documentation/dev-tools/kunit/start.rst
+++ b/Documentation/dev-tools/kunit/start.rst
@@ -197,7 +197,7 @@ Now add the following to ``drivers/misc/Kconfig``:
config MISC_EXAMPLE_TEST
bool "Test for my example"
- depends on MISC_EXAMPLE && KUNIT
+ depends on MISC_EXAMPLE && KUNIT=y
and the following to ``drivers/misc/Makefile``:
diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst
index 3c3fe8b5fecc..410380fc7fb4 100644
--- a/Documentation/dev-tools/kunit/usage.rst
+++ b/Documentation/dev-tools/kunit/usage.rst
@@ -556,6 +556,11 @@ Once the kernel is built and installed, a simple
...will run the tests.
+.. note::
+ Note that you should make your test depends on ``KUNIT=y`` in Kcofig if the
+ test does not support module build. Otherwise, it will trigger compile
+ errors if ``CONFIG_KUNIT`` is ``m``.
+
Writing new tests for other architectures
-----------------------------------------
--
2.17.1