From: Petr Vorel <pvorel@suse.cz>
To: Li Wang <liwang@redhat.com>
Cc: Ricardo Branco <rbranco@suse.com>, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH] userfaultfd05: handle kernels rejecting WP feature in UFFDIO_API
Date: Fri, 23 Jan 2026 13:25:45 +0100 [thread overview]
Message-ID: <20260123122545.GA122331@pevik> (raw)
In-Reply-To: <CAEemH2dUZcuX7PoXGM2OgdB7O9F=ctoYjcWpLDA7tGxHYJqp3g@mail.gmail.com>
> > Yes, for the discussion when to use I'd propose to *not* use kconfig
Maybe to correct myself:
*Use* kconfig if there is no other way to detect the functionality [1].
We prefer to use kconfig detection, but do *not* use kconfig when there is
another way to detect the functionality (e.g. via detecting functionality via
/proc|sys) *and* and one of these three rules:
> > * boot parameter to enable/disable exist
* allow to disable via kernel boot parameter or via /sys file
=> because it can be disabled
> > * check for tristate (functionality which can be compiled as module)
=> modul might not be available
> > * kernel new functionality which is unlikely to be backported (use .min_kver instead)
=> probably faster
> That sounds great to me.
Thank you!
> And, plus one more:
> * kconfig file may be unavailable for some reasons
Yes, but we gave up on this (or at least Cyril) [1]:
As for the missing config there is 95 testcases that have needs_kconfigs
set at this moment and the number is growing steadily. I would argue
that you cannot run LTP without having config available. And the config
location is autodetected on common distributions as well.
me: + at least 2 IMA tests require kconfig via tst_require_kconfigs().
Therefore I accepted it and I'm not against using kconfig. But I would prefer
using it only when it works reliably (100%).
Kind regards,
Petr
[1] https://lore.kernel.org/ltp/aV6DCbns02E4BCTj@yuki.lan/
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-01-23 12:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-23 5:40 [LTP] [PATCH] userfaultfd05: handle kernels rejecting WP feature in UFFDIO_API Li Wang via ltp
2026-01-23 9:45 ` Petr Vorel
2026-01-23 11:34 ` Li Wang via ltp
2026-01-23 11:53 ` Petr Vorel
2026-01-23 12:02 ` Li Wang via ltp
2026-01-23 12:25 ` Petr Vorel [this message]
2026-01-26 6:02 ` Li Wang via ltp
2026-01-27 12:48 ` Cyril Hrubis
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=20260123122545.GA122331@pevik \
--to=pvorel@suse.cz \
--cc=liwang@redhat.com \
--cc=ltp@lists.linux.it \
--cc=rbranco@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.