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

Petr Vorel
2026-01-28T12:45:51Z

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.