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 dlatypov@google.com --- 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
On Thu, Jul 15, 2021 at 7:15 AM Daniel Latypov dlatypov@google.com 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 dlatypov@google.com
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 davidgow@google.com wrote:
On Thu, Jul 15, 2021 at 7:15 AM Daniel Latypov dlatypov@google.com 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 dlatypov@google.com
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
linux-kselftest-mirror@lists.linaro.org