Linux Test Project
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Andrea Cervesato <andrea.cervesato@suse.com>
Cc: ltp@lists.linux.it
Subject: [LTP] [RFC] Re: lib: Rename function check_kver() => check_min_kver()
Date: Mon, 3 Aug 2026 15:06:45 +0200	[thread overview]
Message-ID: <20260803130645.GA246496@pevik> (raw)
In-Reply-To: <6a6c98c6.3c943127.1c122.1c09@mx.google.com>

Hi all,

> > In that case we want to have both in a single commit, right?
> > => yet another version.

> Yes, I think so

I'm not sure what's reasonable, therefore RFC please.

We can for sure can have test with both flags, .min_kver < .max_kver:

.min_kver = "6.5"
.max_kver = "7.2"

which will be tested on kernels <6.5, 7.2> (including all their stable
versions). Here the code works like (using AND):

$(uname -r) >= .min_kver && $(uname -r) <= .max_kver

(BTW although current version prints only the version which is not sufficient.
And I think it's better than print the range without specifying which version is
not sufficient).

But can we have also a variant when .min_kver > .max_kver (using OR)?

.max_kver = "6.10"
.min_kver = "7.2"

i.e it will be tested on <whatever_minimum_LTP is, 6.10> <7.2, future versions>:

$(uname -r) <= .max_kver || $(uname -r) >= .min_kver

Advantages:
* only 2 flags
* no need to parse complicated expressions (e.g. "< 6.9, > 7.1" or "le 6.10, ge 7.2")

Disadvantages
* a bit unintuitive
* complicated expressions will not work

WDYT?

Kind regards,
Petr

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

  reply	other threads:[~2026-08-03 13:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-31 10:51 [LTP] [PATCH v3 0/5] Add support for .max_kver Petr Vorel
2026-07-31 10:51 ` [LTP] [PATCH v3 1/5] lib: Rename function check_kver() => check_min_kver() Petr Vorel
2026-07-31 11:52   ` [LTP] " linuxtestproject.agent
2026-07-31 12:20     ` Petr Vorel
2026-07-31 12:37       ` Andrea Cervesato via ltp
2026-07-31 12:42         ` Petr Vorel
2026-07-31 12:44           ` Andrea Cervesato via ltp
2026-08-03 13:06             ` Petr Vorel [this message]
2026-08-04  5:33               ` [LTP] [RFC] " Li Wang
2026-08-04  6:15                 ` Li Wang
2026-08-04 12:02                   ` Petr Vorel
2026-08-03 13:13         ` [LTP] " Cyril Hrubis
2026-08-03 13:42           ` Petr Vorel
2026-07-31 10:51 ` [LTP] [PATCH v3 2/5] lib: Add support for max_kver to struct tst_test and tst_fs Petr Vorel
2026-07-31 11:48   ` Avinesh Kumar via ltp
2026-07-31 10:51 ` [LTP] [PATCH v3 3/5] execve04: Use .max_kver Petr Vorel
2026-07-31 10:51 ` [LTP] [PATCH v3 4/5] creat07: " Petr Vorel
2026-07-31 10:51 ` [LTP] [PATCH v3 5/5] fanotify20: Skip on v7.2 Petr Vorel

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=20260803130645.GA246496@pevik \
    --to=pvorel@suse.cz \
    --cc=andrea.cervesato@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox