From: John Harrison <john.c.harrison@intel.com>
To: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Kamil Konieczny <kamil.konieczny@linux.intel.com>,
<IGT-Dev@lists.freedesktop.org>,
Katarzyna Piecielska <katarzyna.piecielska@intel.com>
Subject: Re: [RFC i-g-t] kunit: Remove hard-coded test list from xe_live_ktest
Date: Fri, 13 Sep 2024 17:20:32 -0700 [thread overview]
Message-ID: <84c6520c-b634-4be3-89fd-98595b537cb8@intel.com> (raw)
In-Reply-To: <1942260.taCxCBeP46@jkrzyszt-mobl2.ger.corp.intel.com>
On 8/29/2024 02:57, Janusz Krzysztofik wrote:
> Hi John,
>
> On Wednesday, 28 August 2024 20:04:06 GMT+2 John Harrison wrote:
>> On 8/26/2024 06:07, Janusz Krzysztofik wrote:
>>> Hi John, Kamil,
>>>
>>> On Monday, 26 August 2024 13:46:45 GMT+2 Kamil Konieczny wrote:
>>>> Hi John.C.Harrison,
>>>> On 2024-08-23 at 11:24:18 -0700, John.C.Harrison@Intel.com wrote:
>>>>> From: johnharr <johnharr@invalid-email.com>
>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> Again invalid e-mail here.
>>>>
>>>>> The list of supported kunit tests is currently hard coded.
>>> That pattern originates from i915_selftest, where there are 3 stable subtests,
>>> "mock", "live" and "perf", each of them executing a (possibly long) list of
>>> dynamic sub-subtests actually provided by the module for each category. Also,
>>> IIRC there was a separate module for each Xe test suite before, each mapped to
>>> a separate IGT test, later merged into one module with multiple suites and one
>>> test with multiple corresponding subtests.
>> Not sure if you are just explaining the history of the test or making a
>> suggestion as to how it should evolve next?
> Both, I think. Maybe not the history, but origin of ideas standing behind the
> implementation, and how tests are expected to use it (and maybe evolve if now
> doing that in a different way).
>
>>>>> Which means
>>>>> that adding a new test to the kernel also requires patches to IGT as
>>>>> well.
>>>>>
>>>>> The list of available kunit tests is already exported by the kernel.
>>>>> So there is no need to bake a list into the IGT source code. So, add
>>>>> support for querying the test list dynamically.
>>>>>
>>>>> NB: Currently, the test list can only be queried by root but the IGT
>>>>> build system queries all tests at compile time. In theory this should
>>>>> not be a problem. However, the kunit helper code is all written to run
>>>>> inside a test and not inside the prep code, which means that when it
>>>>> fails to open the root only interfaces, it calls 'skip'. And skip is
>>>>> not allowed outside of running a test. Hence the build fails with:
>>>>> skipping is allowed only in fixtures, subtests or igt_simple_main
>>>> Looks like we should fix it, move out skips from kunit libs.
>>> I suggest you consider a different approach: for a module, call igt_kunit()
>>> only once, with NULL suite argument. As a result, you'll get results from one
>>> IGT subtest called "<module_name>" with a bunch of IGT dynamic sub-subtests
>>> called "<test_suite>-<test_case>", one for each test case provided by the
>>> module.
>> I'm not following. This is what my patch does, isn't it?
> No, your patch introduces a runtime determined list of subtests -- something
> not existent in IGT.
>
> An IGT test may consist of one or more statically defined subtests with pre-
> defined names. The term dynamic subtest is usually used in two meanings. It
> may mean a subtest of type igt_subtest_with_dynamic, still with a pre-defined
> name, but with a runtime determined list of sub-subtests, sometimes called
> dynamic sub-subtests, but often also called just dynamic subtests. Names of
> dynamic sub-subtests are determined at runtime.
>
> My approach tries to address your need for a maintenance-free kunit IGT test
> source file in a different way. I'm following the IGT standard of statically
> defined list of subtests with pre-defined names: one subtest of type
> igt_subtest_with_dynamic, named after the kunit test module name which you
> have to enter into the test code anyway, and providing all test cases from
> all test suites contained in that module reported as dynamic sub-subtests
> named <test_suite>-<test_case>.
Can you please prototype how to do this? I can read your words but I
don't really get your meaning and I have no clue how to implement what
you are saying.
John.
next prev parent reply other threads:[~2024-09-14 0:20 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-23 18:24 [RFC i-g-t] kunit: Remove hard-coded test list from xe_live_ktest John.C.Harrison
2024-08-23 21:56 ` ✗ Fi.CI.BUILD: failure for " Patchwork
2024-08-23 22:05 ` ✗ GitLab.Pipeline: warning " Patchwork
2024-08-26 11:46 ` [RFC i-g-t] " Kamil Konieczny
2024-08-26 13:07 ` Janusz Krzysztofik
2024-08-28 18:04 ` John Harrison
2024-08-29 9:57 ` Janusz Krzysztofik
2024-08-29 10:40 ` Janusz Krzysztofik
2024-08-29 10:45 ` Janusz Krzysztofik
2024-09-14 0:20 ` John Harrison [this message]
2024-09-16 8:17 ` Janusz Krzysztofik
2024-09-16 22:10 ` John Harrison
2024-09-17 9:14 ` Janusz Krzysztofik
2024-08-28 18:03 ` John Harrison
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=84c6520c-b634-4be3-89fd-98595b537cb8@intel.com \
--to=john.c.harrison@intel.com \
--cc=IGT-Dev@lists.freedesktop.org \
--cc=janusz.krzysztofik@linux.intel.com \
--cc=kamil.konieczny@linux.intel.com \
--cc=katarzyna.piecielska@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox