kunit.py currently does not make it possible for users to specify module
parameters (/kernel arguments more generally) unless one directly tweaks
the kunit.py code itself.
This hasn't mattered much so far, but this would make it easier to port
existing tests that expose module parameters over to KUnit and/or let
current KUnit tests take advantage of them.
Tested using an kunit internal parameter:
$ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit \
--kernel_args=kunit.filter_glob=kunit_status
...
Testing complete. 2 tests run. 0 failed. 0 crashed. 0 skipped.
Signed-off-by: Daniel Latypov <[email protected]>
---
v1 -> v2:
s/kernel_arg/kernel_args in documentation
---
Documentation/dev-tools/kunit/running_tips.rst | 10 ++++++++++
tools/testing/kunit/kunit.py | 16 ++++++++++++----
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/Documentation/dev-tools/kunit/running_tips.rst b/Documentation/dev-tools/kunit/running_tips.rst
index 7d99386cf94a..ebaaa2764207 100644
--- a/Documentation/dev-tools/kunit/running_tips.rst
+++ b/Documentation/dev-tools/kunit/running_tips.rst
@@ -80,6 +80,16 @@ file ``.kunitconfig``, you can just pass in the dir, e.g.
automagically, but tests could theoretically depend on incompatible
options, so handling that would be tricky.
+Setting kernel commandline parameters
+-------------------------------------
+
+You can use ``--kernel_args`` to pass arbitrary kernel arguments, e.g.
+
+.. code-block:: bash
+
+ $ ./tools/testing/kunit/kunit.py run --kernel_args=param=42 --kernel_args=param2=false
+
+
Generating code coverage reports under UML
------------------------------------------
diff --git a/tools/testing/kunit/kunit.py b/tools/testing/kunit/kunit.py
index be8d8d4a4e08..03f3bc406955 100755
--- a/tools/testing/kunit/kunit.py
+++ b/tools/testing/kunit/kunit.py
@@ -28,12 +28,13 @@ KunitBuildRequest = namedtuple('KunitBuildRequest',
['jobs', 'build_dir', 'alltests',
'make_options'])
KunitExecRequest = namedtuple('KunitExecRequest',
- ['timeout', 'build_dir', 'alltests', 'filter_glob'])
+ ['timeout', 'build_dir', 'alltests',
+ 'filter_glob', 'kernel_args'])
KunitParseRequest = namedtuple('KunitParseRequest',
['raw_output', 'input_data', 'build_dir', 'json'])
KunitRequest = namedtuple('KunitRequest', ['raw_output','timeout', 'jobs',
'build_dir', 'alltests', 'filter_glob',
- 'json', 'make_options'])
+ 'kernel_args', 'json', 'make_options'])
KernelDirectoryPath = sys.argv[0].split('tools/testing/kunit/')[0]
@@ -92,6 +93,7 @@ def exec_tests(linux: kunit_kernel.LinuxSourceTree,
kunit_parser.print_with_timestamp('Starting KUnit Kernel ...')
test_start = time.time()
result = linux.run_kernel(
+ args=request.kernel_args,
timeout=None if request.alltests else request.timeout,
filter_glob=request.filter_glob,
build_dir=request.build_dir)
@@ -150,7 +152,8 @@ def run_tests(linux: kunit_kernel.LinuxSourceTree,
return build_result
exec_request = KunitExecRequest(request.timeout, request.build_dir,
- request.alltests, request.filter_glob)
+ request.alltests, request.filter_glob,
+ request.kernel_args)
exec_result = exec_tests(linux, exec_request)
if exec_result.status != KunitStatus.SUCCESS:
return exec_result
@@ -236,6 +239,9 @@ def add_exec_opts(parser) -> None:
nargs='?',
default='',
metavar='filter_glob')
+ parser.add_argument('--kernel_args',
+ help='Kernel command-line parameters. Maybe be repeated',
+ action='append')
def add_parse_opts(parser) -> None:
parser.add_argument('--raw_output', help='don\'t format output from kernel',
@@ -307,6 +313,7 @@ def main(argv, linux=None):
cli_args.build_dir,
cli_args.alltests,
cli_args.filter_glob,
+ cli_args.kernel_args,
cli_args.json,
cli_args.make_options)
result = run_tests(linux, request)
@@ -361,7 +368,8 @@ def main(argv, linux=None):
exec_request = KunitExecRequest(cli_args.timeout,
cli_args.build_dir,
cli_args.alltests,
- cli_args.filter_glob)
+ cli_args.filter_glob,
+ cli_args.kernel_args)
exec_result = exec_tests(linux, exec_request)
parse_request = KunitParseRequest(cli_args.raw_output,
exec_result.result,
base-commit: 8096acd7442e613fad0354fc8dfdb2003cceea0b
--
2.32.0.93.g670b81a890-goog
On Thu, Jul 15, 2021 at 7:15 AM Daniel Latypov <[email protected]> wrote:
>
> kunit.py currently does not make it possible for users to specify module
> parameters (/kernel arguments more generally) unless one directly tweaks
> the kunit.py code itself.
>
> This hasn't mattered much so far, but this would make it easier to port
> existing tests that expose module parameters over to KUnit and/or let
> current KUnit tests take advantage of them.
>
> Tested using an kunit internal parameter:
> $ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit \
> --kernel_args=kunit.filter_glob=kunit_status
> ...
> Testing complete. 2 tests run. 0 failed. 0 crashed. 0 skipped.
>
> Signed-off-by: Daniel Latypov <[email protected]>
Thanks! This is probably overdue: while I still think we want to avoid
this being necessary for most uses, it definitely was a gap in
kunit_tool functionality.
I tested this and it worked fine, but did cause several of the
kunit_tool_tests to fail, largely due to there being changes to the
arguments of run_kernel(). Those should just require the associated
tests to be updated.
-- David
On Wed, Jul 14, 2021 at 11:14 PM David Gow <[email protected]> wrote:
>
> On Thu, Jul 15, 2021 at 7:15 AM Daniel Latypov <[email protected]> wrote:
> >
> > kunit.py currently does not make it possible for users to specify module
> > parameters (/kernel arguments more generally) unless one directly tweaks
> > the kunit.py code itself.
> >
> > This hasn't mattered much so far, but this would make it easier to port
> > existing tests that expose module parameters over to KUnit and/or let
> > current KUnit tests take advantage of them.
> >
> > Tested using an kunit internal parameter:
> > $ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit \
> > --kernel_args=kunit.filter_glob=kunit_status
> > ...
> > Testing complete. 2 tests run. 0 failed. 0 crashed. 0 skipped.
> >
> > Signed-off-by: Daniel Latypov <[email protected]>
>
> Thanks! This is probably overdue: while I still think we want to avoid
> this being necessary for most uses, it definitely was a gap in
> kunit_tool functionality.
>
> I tested this and it worked fine, but did cause several of the
> kunit_tool_tests to fail, largely due to there being changes to the
> arguments of run_kernel(). Those should just require the associated
> tests to be updated.
Oops, completely forgot about kunit_tool_test.py. Sent out a v3.
I also went and added a test case to make sure the flag can be
repeated and gets plumbed through properly.
>
> -- David