[LTP] [PATCH 1/1] doc/ground_rules: Add Kernel features check rules

[LTP] [PATCH 1/1] doc/ground_rules: Add Kernel features check rules

[Petr Vorel]

Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
Based on a discussion various discussions:
https://lore.kernel.org/ltp/20260123122545.GA122331@pevik/
https://lore.kernel.org/ltp/20260128072445.GB13495@pevik/

Kind regards,
Petr

 doc/developers/ground_rules.rst | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/doc/developers/ground_rules.rst b/doc/developers/ground_rules.rst
index 05e473cad5..90fe7a64ee 100644
--- a/doc/developers/ground_rules.rst
+++ b/doc/developers/ground_rules.rst
@@ -174,3 +174,20 @@ These patches should also add a [STAGING] keyword into the patch subject, e.g.
 In a case that a test for unreleased kernel is really needed to be merged we do
 not add it to the list of test executed by default and keep it in
 :master:`runtest/staging` file until the kernel code is finalized.
+
+Kernel features check
+---------------------
+
+We prefer to use :c:type:`.needs_kconfigs <tst_test>` (kernel kconfig check).
+But do *not* use it when there is another way to detect the functionality (e.g.
+via detecting functionality via ``/proc|sys``) *and* any of these rules applies:
+
+- Kernel allows to disable functionality via `kernel’s command-line parameter
+  <https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html>`_
+  (it can be disabled in runtime).
+- It's a check for a functionality which can be compiled as module
+  (`tristate
+  <https://docs.kernel.org/kbuild/kconfig-language.html#menu-attributes>`_,
+  modul might not be available).
+- New kernel functionality which is unlikely to be backported (use
+  :c:type:`.min_kver <tst_test>` instead).
-- 
2.51.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/1] doc/ground_rules: Add Kernel features check rules

[Li Wang via ltp]

Hi Petr,

Generally looks good, just a few comments to polish it.

Reviewed-by: Li Wang <liwang@redhat.com>


On Wed, Jan 28, 2026 at 4:01 PM Petr Vorel <pvorel@suse.cz> wrote:

> Signed-off-by: Petr Vorel <pvorel@suse.cz>
> ---
> Based on a discussion various discussions:
> https://lore.kernel.org/ltp/20260123122545.GA122331@pevik/
> https://lore.kernel.org/ltp/20260128072445.GB13495@pevik/
>
> Kind regards,
> Petr
>
>  doc/developers/ground_rules.rst | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>
> diff --git a/doc/developers/ground_rules.rst
> b/doc/developers/ground_rules.rst
> index 05e473cad5..90fe7a64ee 100644
> --- a/doc/developers/ground_rules.rst
> +++ b/doc/developers/ground_rules.rst
> @@ -174,3 +174,20 @@ These patches should also add a [STAGING] keyword
> into the patch subject, e.g.
>  In a case that a test for unreleased kernel is really needed to be merged
> we do
>  not add it to the list of test executed by default and keep it in
>  :master:`runtest/staging` file until the kernel code is finalized.
> +
> +Kernel features check
> +---------------------
> +
> +We prefer to use :c:type:`.needs_kconfigs <tst_test>` (kernel kconfig
> check).
> +But do *not* use it when there is another way to detect the functionality
> (e.g.
> +via detecting functionality via ``/proc|sys``) *and* any of these rules
> applies:
>

Perhaps replace "detect" with "impact"?



> +- Kernel allows to disable functionality via `kernel’s command-line
> parameter
> +  <
> https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
> >`_
> +  (it can be disabled in runtime).
>

- Runtime-disable possible: kernel exposes a command-line parameter
   (or runtime knob) that can enable/disable the functionality, so a
build-time
   kconfig does not reflect runtime availability.

+- It's a check for a functionality which can be compiled as module
> +  (`tristate
> +  <https://docs.kernel.org/kbuild/kconfig-language.html#menu-attributes
> >`_,
> +  modul might not be available).
>

- Tristate/module feature: The functionality is controlled by a
   `tristate <
https://docs.kernel.org/kbuild/kconfig-language.html#menu-attributes>`_
    option (i.e. it may be built as a module), and the module might not be
present
    or loaded at runtime.


> +- New kernel functionality which is unlikely to be backported (use
> +  :c:type:`.min_kver <tst_test>` instead).


- New non-backported functionality: The test targets a new upstream kernel
feature
   that is unlikely to be backported. Prefer :c:type:`.min_kver <tst_test>`
for gating
   instead of Kconfig symbols.


-- 
Regards,
Li Wang

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/1] doc/ground_rules: Add Kernel features check rules

[Petr Vorel]

Hi Li,

> Hi Petr,

> Generally looks good, just a few comments to polish it.

Thank you! All followed suggestions makes sense to me. I can fix that before
merge (unless somebody prefers me to send v2).

It'd be nice to get this resolved so that we have this fix merged
(related to this policy):
https://github.com/linux-test-project/ltp/pull/1285

Kind regards,
Petr

> Reviewed-by: Li Wang <liwang@redhat.com>


> On Wed, Jan 28, 2026 at 4:01 PM Petr Vorel <pvorel@suse.cz> wrote:

> > Signed-off-by: Petr Vorel <pvorel@suse.cz>
> > ---
> > Based on a discussion various discussions:
> > https://lore.kernel.org/ltp/20260123122545.GA122331@pevik/
> > https://lore.kernel.org/ltp/20260128072445.GB13495@pevik/

> > Kind regards,
> > Petr

> >  doc/developers/ground_rules.rst | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)

> > diff --git a/doc/developers/ground_rules.rst
> > b/doc/developers/ground_rules.rst
> > index 05e473cad5..90fe7a64ee 100644
> > --- a/doc/developers/ground_rules.rst
> > +++ b/doc/developers/ground_rules.rst
> > @@ -174,3 +174,20 @@ These patches should also add a [STAGING] keyword
> > into the patch subject, e.g.
> >  In a case that a test for unreleased kernel is really needed to be merged
> > we do
> >  not add it to the list of test executed by default and keep it in
> >  :master:`runtest/staging` file until the kernel code is finalized.
> > +
> > +Kernel features check
> > +---------------------
> > +
> > +We prefer to use :c:type:`.needs_kconfigs <tst_test>` (kernel kconfig
> > check).
> > +But do *not* use it when there is another way to detect the functionality
> > (e.g.
> > +via detecting functionality via ``/proc|sys``) *and* any of these rules
> > applies:


> Perhaps replace "detect" with "impact"?



> > +- Kernel allows to disable functionality via `kernel’s command-line
> > parameter
> > +  <
> > https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
> > >`_
> > +  (it can be disabled in runtime).


> - Runtime-disable possible: kernel exposes a command-line parameter
>    (or runtime knob) that can enable/disable the functionality, so a
> build-time
>    kconfig does not reflect runtime availability.

> +- It's a check for a functionality which can be compiled as module
> > +  (`tristate
> > +  <https://docs.kernel.org/kbuild/kconfig-language.html#menu-attributes
> > >`_,
> > +  modul might not be available).


> - Tristate/module feature: The functionality is controlled by a
>    `tristate <
> https://docs.kernel.org/kbuild/kconfig-language.html#menu-attributes>`_
>     option (i.e. it may be built as a module), and the module might not be
> present
>     or loaded at runtime.


> > +- New kernel functionality which is unlikely to be backported (use
> > +  :c:type:`.min_kver <tst_test>` instead).


> - New non-backported functionality: The test targets a new upstream kernel
> feature
>    that is unlikely to be backported. Prefer :c:type:`.min_kver <tst_test>`
> for gating
>    instead of Kconfig symbols.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/1] doc/ground_rules: Add Kernel features check rules

[Petr Vorel]

> Signed-off-by: Petr Vorel <pvorel@suse.cz>
> ---
> Based on a discussion various discussions:
> https://lore.kernel.org/ltp/20260123122545.GA122331@pevik/
> https://lore.kernel.org/ltp/20260128072445.GB13495@pevik/

> Kind regards,
> Petr

>  doc/developers/ground_rules.rst | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)

> diff --git a/doc/developers/ground_rules.rst b/doc/developers/ground_rules.rst
> index 05e473cad5..90fe7a64ee 100644
> --- a/doc/developers/ground_rules.rst
> +++ b/doc/developers/ground_rules.rst
> @@ -174,3 +174,20 @@ These patches should also add a [STAGING] keyword into the patch subject, e.g.
>  In a case that a test for unreleased kernel is really needed to be merged we do
>  not add it to the list of test executed by default and keep it in
>  :master:`runtest/staging` file until the kernel code is finalized.
> +
> +Kernel features check
> +---------------------
> +
> +We prefer to use :c:type:`.needs_kconfigs <tst_test>` (kernel kconfig check).
> +But do *not* use it when there is another way to detect the functionality (e.g.
> +via detecting functionality via ``/proc|sys``) *and* any of these rules applies:
> +
> +- Kernel allows to disable functionality via `kernel’s command-line parameter
> +  <https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html>`_
> +  (it can be disabled in runtime).
> +- It's a check for a functionality which can be compiled as module
> +  (`tristate
> +  <https://docs.kernel.org/kbuild/kconfig-language.html#menu-attributes>`_,
> +  modul might not be available).
> +- New kernel functionality which is unlikely to be backported (use
> +  :c:type:`.min_kver <tst_test>` instead).

I wonder how about .needs_kconfigs vs. needs_drivers. Do we prefer any of these?
I suppose the rule could be .needs_drivers when nothing specific from module is
needed, .needs_kconfigs otherwise.

https://patchwork.ozlabs.org/project/ltp/patch/20260122150652.227342-1-kushalkataria5@gmail.com/

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/1] doc/ground_rules: Add Kernel features check rules

[Li Wang via ltp]

> I wonder how about .needs_kconfigs vs. needs_drivers. Do we prefer any of these?
> I suppose the rule could be .needs_drivers when nothing specific from module is
> needed, .needs_kconfigs otherwise.

Hmm, this looks only belongs to the second section.
Maybe:

  - Tristate/module feature: If the functionality is controlled by a Kconfig of
     type tristate (`tristate
<https://docs.kernel.org/kbuild/kconfig-language.html#menu-attributes>`_),
     it might be built as a module. Modules can be absent or unloaded
at runtime,
     so checking the Kconfig option alone isn’t enough. Instead of
.needs_kconfigs,
     rely on .needs_drivers or a runtime check to confirm the module is loaded.


-- 
Regards,
Li Wang


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/1] doc/ground_rules: Add Kernel features check rules

[Cyril Hrubis]

Hi!
> > I wonder how about .needs_kconfigs vs. needs_drivers. Do we prefer any of these?
> > I suppose the rule could be .needs_drivers when nothing specific from module is
> > needed, .needs_kconfigs otherwise.
> 
> Hmm, this looks only belongs to the second section.
> Maybe:
> 
>   - Tristate/module feature: If the functionality is controlled by a Kconfig of
>      type tristate (`tristate
> <https://docs.kernel.org/kbuild/kconfig-language.html#menu-attributes>`_),
>      it might be built as a module. Modules can be absent or unloaded
> at runtime,
>      so checking the Kconfig option alone isn’t enough. Instead of
> .needs_kconfigs,
>      rely on .needs_drivers or a runtime check to confirm the module is loaded.

Sounds good to me.

-- 
Cyril Hrubis
chrubis@suse.cz

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/1] doc/ground_rules: Add Kernel features check rules

[Andrea Cervesato via ltp]

Hi!

Is this patch still valid? Should we merge it with minor details as
suggested?

Kind regards,
-- 
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/1] doc/ground_rules: Add Kernel features check rules

[Petr Vorel]

Hi all,

> Hi!

> Is this patch still valid? Should we merge it with minor details as
> suggested?

I planned to merge this with change Li suggested [1]. But in a meanwhile Cyril
posted lib: tst_kconfig: Add runtime checks [2]. Once he finds time to merge it,
I should probably send v2 of this patch - update Li's suggestion:

  - Tristate/module feature: If the functionality is controlled by a Kconfig of
     type tristate (`tristate
<https://docs.kernel.org/kbuild/kconfig-language.html#menu-attributes>`_),
     it might be built as a module. Modules can be absent or unloaded
at runtime,
     so checking the Kconfig option alone isn’t enough. .needs_kconfigs,
	 requires to add additional kconfig checks to confirm the module is loaded.

Also, Cyril noted [3] on thermal test that using .supported_archs is also useful
to define which arch is targeted (when used with .needs_drivers/.needs_kconfigs,
which would be enough for detecting the functionality). Do we want to add it as
a rule?
	- Test targeted to a certain architecture should always use .supported_archs
	even if this is not necessary as a check because test already define
	.needs_drivers/.needs_kconfigs.

And back to my question some time ago. Do we want to deprecate .needs_drivers,
when Cyril enhanced .needs_kconfigs? Do we even need it?

Kind regards,
Petr

> Kind regards,

[1] https://lore.kernel.org/ltp/CAEemH2fc_C_vGnKtbYqsMzMVKLSNLhCFWLGemSyVTWBzAATDCA@mail.gmail.com/
[2] https://patchwork.ozlabs.org/project/ltp/patch/20260205135724.23772-1-chrubis@suse.cz/
[3] https://lore.kernel.org/ltp/aa_0YkA4UKwhOjpi@yuki.lan/

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/1] doc/ground_rules: Add Kernel features check rules

[Petr Vorel]

Hi all,

FYI Andrea's patchset for AI agents [1] somehow duplicate this info.
ATM we don't know how to combine these two things [2].

Kind regards,
Petr

[1] https://patchwork.ozlabs.org/project/ltp/patch/20260224-agents_file-v6-1-db15c490d048@suse.com/
[2] https://lore.kernel.org/ltp/69aedf8b.050a0220.24143c.7ce1@mx.google.com/

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp