All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Avinesh Kumar <avinesh.kumar@suse.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v2 2/5] lib: Add support for max_kver to struct tst_test and tst_fs
Date: Thu, 30 Jul 2026 16:08:28 +0200	[thread overview]
Message-ID: <20260730140828.GA83115@pevik> (raw)
In-Reply-To: <5e27b4ff-af04-49ef-a830-934164486892@suse.com>

Hi Avinesh,

> > > > - * @min_kver: A minimal kernel version the test can run on. e.g. "3.10".
> > > > + * @min_kver: A minimal kernel version the test can run on. e.g. "4.4".
> > > s/minimal/minimum

> > You spotted more grammar errors so I trust you :). But can you please double
> > check that it'đ really correct? Minimal is an adjective, minimum is an adjective
> > but also a noun and an adverb.

> > When googling I even found use of both in the same document :)
> > https://kubernetes.io/docs/reference/node/kernel-version-requirements/
> > "have minimum kernel version requirements"
> > "minimal kernel version requirement"
> I see we are using minimal in many places already. I think both wordings
> are correct. Just that 'maximal kernel version' sounded a bit odd to me.
> So please ignore my comment here.

Np.

> > > > + *
> > > > + * @max_kver: A maximal kernel version the test can run on. e.g. "7.2".
> > > s/maximal/maximum
> > dtto

> > > Also, I assume test will *not be skipped* on kernel versions
> > > 7.1.1, 7.1.2 etc just with
> > > .max_kver="7.1"

> > Good point, thanks => v3 (sigh).

> > check_max_kver() needs to have this condition to take an account the sublevel.

> > -if (tst_kvercmp(v1, v2, v3) > 0) {
> > +if (tst_kvercmp(v1, v2, v3) >= 1024) {
> > 		msg = "The test requires kernel %s or older";
> And will this be fine with -
> .max_kver="7.1.5"
> on SUT with v7.2.0 ?

Indeed, this will not be skipped. The reason is that for .max_kver="7.1"
(e.g. without the 3rd number) we want to behave like 7.1.1023 (i.e. 3rd number
being the highest possible number so that any 7.1 version is ok, which is
achieved by > 1024 instead of 0). If we want also .max_kver="7.1.5" compare
as is (i.e. 7.1.5), it should be something like (untested):

if (tst_kvercmp(v1, v2, v3) > (!v3 ? 1023 : 0)) {
	msg = "The test requires kernel %s or older";

And that behavior would have to be for sure well documented.
WDYT?

> sorry, haven't tested yet.

> > ...

> > Sublevel can be above 255 since 4.4.256
> > https://lwn.net/ml/linux-kernel/20210208145805.898658055@linuxfoundation.org/
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9b82f13e7ef3

> > But it should be below 1024 (practically the highest sublevel has been 337).

> > Kind regards,
> > Petr

> > > maybe we should clarify.

> > > >     *
> > > >     * @supported_archs: A NULL terminated array of architectures the test runs on
> > > >     *                   e.g. {"x86_64, "x86", NULL}. Calls tst_is_on_arch() to
> > > > @@ -551,6 +557,7 @@ struct tst_fs {
> > > >    	struct tst_option *options;
> > > >    	const char *min_kver;
> > > > +	const char *max_kver;
> > > >    	const char *const *supported_archs;
> > > > diff --git a/lib/tst_test.c b/lib/tst_test.c
> > > > index 778a1fed40..fa38b3a7a3 100644
> > > > --- a/lib/tst_test.c
> > > > +++ b/lib/tst_test.c
> > > > @@ -1087,6 +1087,36 @@ static bool check_min_kver(const char *min_kver, const int brk_nosupp)
> > > >    	return true;
> > > >    }
> > > > +/*
> > > > + * Check for the maximal required kernel version.
> > > > + *
> > > > + * return: true if the kernel version is low enough, false otherwise.

> > > This sounds a bit confusing. How about-

> > > Check the running kernel against the last version the test applies to.

> > Makes sense. Based on check_min_kver(), which was renamed from check_kver() in
> > the previous commit. Could you have look on these as well. Anyway, if you have
> > time, having a look on docs wording as a separate effort would help.
> sure, I will see if I find something worth reporting.

+1


> > > return: true if the kernel is old enough, false otherwise.

> > +1

> > > > + */
> > > > +static bool check_max_kver(const char *max_kver, const int brk_nosupp)
> > > > +{
> > > > +	char *msg;
> > > > +	int v1, v2, v3;
> > > > +
> > > > +	if (tst_parse_kver(max_kver, &v1, &v2, &v3)) {
> > > > +		tst_res(TWARN,
> > > > +			"Invalid kernel version %s, expected %%d.%%d.%%d",
> > > I wouldn't say 'kernel version is invalid'. maybe test isn't
> > > supported/applicable on..

> > tst_parse_kver() returns 1 on error => this is really an error check.
> > Other thing is that the same error handling is on both places, but that's very
> > minor.
> sorry, my bad. I misunderstood this. Please ignore.

np.

Kind regards,
Petr

> > Kind regards,
> > Petr
> > ...

> > > Thanks,
> > > Avinesh


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

  reply	other threads:[~2026-07-30 14:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-29  9:57 [LTP] [PATCH v2 0/5] Add support for .max_kver Petr Vorel
2026-07-29  9:57 ` [LTP] [PATCH v2 1/5] lib: Rename function check_kver() => check_min_kver() Petr Vorel
2026-07-30  8:58   ` Avinesh Kumar via ltp
2026-07-29  9:57 ` [LTP] [PATCH v2 2/5] lib: Add support for max_kver to struct tst_test and tst_fs Petr Vorel
2026-07-29 10:40   ` Avinesh Kumar via ltp
2026-07-29 13:36     ` Petr Vorel
2026-07-29 20:19       ` Avinesh Kumar via ltp
2026-07-30 14:08         ` Petr Vorel [this message]
2026-07-29  9:57 ` [LTP] [PATCH v2 3/5] execve04: Use .max_kver Petr Vorel
2026-07-29  9:57 ` [LTP] [PATCH v2 4/5] creat07: " Petr Vorel
2026-07-29  9:57 ` [LTP] [PATCH v2 5/5] fanotify20: Skip on v7.2 Petr Vorel
2026-07-29 10:26   ` Jan Kara
2026-07-29 15:47 ` [LTP] [PATCH v2 0/5] Add support for .max_kver Andrea Cervesato via ltp

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=20260730140828.GA83115@pevik \
    --to=pvorel@suse.cz \
    --cc=avinesh.kumar@suse.com \
    --cc=ltp@lists.linux.it \
    /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.