[PATCH i-g-t v3 0/5] lib/kunit: Execute test cases synchronously
Cavitt, Jonathan
jonathan.cavitt at intel.com
Tue Mar 19 18:39:15 UTC 2024
-----Original Message-----
From: Janusz Krzysztofik <janusz.krzysztofik at linux.intel.com>
Sent: Monday, March 18, 2024 3:13 AM
To: igt-dev at lists.freedesktop.org
Cc: intel-gfx at lists.freedesktop.org; intel-xe at lists.freedesktop.org; Kamil Konieczny <kamil.konieczny at linux.intel.com>; Mauro Carvalho Chehab <mchehab at kernel.org>; Cavitt, Jonathan <jonathan.cavitt at intel.com>; De Marchi, Lucas <lucas.demarchi at intel.com>
Subject: [PATCH i-g-t v3 0/5] lib/kunit: Execute test cases synchronously
>
> Up to now we were loading a KUnit test module in test execution mode only
> once per subtest, in background, and then, in parallel with execution of
> test cases while the module was loading, we were looking through dmesg for
> KTAP results from each expected test case. As a consequence, our IGT
> messages were more or less delayed, never in full sync with kernel
> messages. Moreover, parsing of KTAP results from already completed test
> cases could be abandoned on a failure from loading the test module or
> kernel taint caused by a subsequent test case. Also, parsing of KTAP
> results from all subsequent test cases could be abandoned on a failure of
> the parser caused by any test case. Other than that, if a user requested
> a single dynamic sub-subtest, all test cases were executed anyway while
> results from only one of them that corresponded to the selected dynamic
> sub-subtest were reported. That way, kernel messages from unrelated test
> cases, not only the selected one, could contribute to dmesg-fail or dmesg-
> warn CI results from that sub-subtest.
>
> Since recent KUnit implementation is capable of executing only those test
> cases that match a user filter, stop executing all of them asynchronously
> and parsing their KTAP results as they appear. Instead, reload the test
> module once per each dynamic sub-subtest with a filter that selects a
> specific test case and wait for its completion. If successful and no
> kernel taint has occurred then parse the whole KTAP report from a single
> test case it has produced and translate it to IGT result of that single
> corresponding sub-subtest.
>
> v3: Insert new patches 1-3 that fix an infinite loop when we try to get a
> list of test cases from an unexpectedly missing KTAP report.
> v2: Refresh the series on top of changes to KUnit filters handling,
> - move the code of a new helper from a previous patch 1 to a previous
> patch 2 which now becomes patch 1,
> - actually limit the scope of the helper to fetching a KTAP report from
> a file descriptor, and let the callers decide on how other steps, like
> setting up filters or loading a test module, and errors they return
> are handled,
> - update commit description with a more detailed justification of why we
> need these changes,
> - rebase the former patch 1 on top of the new patch 1, update its commit
> message and description and provide it as patch 2.
>
> Janusz Krzysztofik (5):
> lib/kunit: Store igt_ktap_results pointer in a central location
> lib/kunit: Let igt_ktap_free() take care of pointer reset
> lib/kunit: Time out promptly on missing KTAP report
> lib/kunit: Execute test cases synchronously
> lib/kunit: Minimize code duplication
>
Acked-by: Jonathan Cavitt <jonathan.cavitt at intel.com>
Ack applies to all patches in series.
It seems that Kamil is giving a proper review to all the individual patches,
so I'd wait until that's done before moving forward.
-Jonathan Cavitt
> lib/igt_kmod.c | 193 ++++++++++++++----------------------
> lib/igt_ktap.c | 5 +-
> lib/igt_ktap.h | 2 +-
> lib/tests/igt_ktap_parser.c | 24 ++---
> 4 files changed, 93 insertions(+), 131 deletions(-)
>
> --
> 2.43.0
>
>
More information about the igt-dev
mailing list