[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.