All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Chikunov <vt@altlinux.org>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: Shuah Khan <shuah@kernel.org>,
	linux-kselftest@vger.kernel.org,
	"Dmitry V. Levin" <ldv@altlinux.org>
Subject: Re: Kernel selftests and backward compatibility?
Date: Thu, 24 Jun 2021 16:48:47 +0300	[thread overview]
Message-ID: <20210624134847.zoms7776gm6d3q2k@altlinux.org> (raw)
In-Reply-To: <a068b01b-9549-3c6b-f0c5-7c68e9bc1c23@linuxfoundation.org>

Shuah,

On Wed, Jun 23, 2021 at 12:08:48PM -0600, Shuah Khan wrote:
> On 6/23/21 8:26 AM, Vitaly Chikunov wrote:
> > Do kselftests require to be backward-compatible?
> 
> Kselftests from the latest kernel can run on older kernels. In that
> respect they are backward compatible.
> 
> It is possible that a newly added test is for a new feature and new
> API and as a result could be skipped on older kernels.
> 
> 
> 
> > I see Documentation/dev-tools/kselftest.rst does not require this, but
> > maybe it's assumed like in other test suites (or in perf).
> > 
> > | In general, the rules for selftests are
> > |
> > |  * Do as much as you can if you're not root;
> > |
> > |  * Don't take too long;
> > |
> > |  * Don't break the build on any architecture, and
> > |
> > |  * Don't cause the top-level "make run_tests" to fail if your feature is
> > |    unconfigured.
> > 
> 
> Correct. We don't explicitly state that the tests are backward
> compatible, however they are. We don't do any revision checks.
> We keep adding new tests and enhancements to existing tests in
> every release. New tests depend on new kernel features and headers
> and they could fail to build. However the suite will build the tests
> it can build and will run the test it can run.
> 
> > For example LTP says:
> > 
> > | LTP test should be as backward compatible as possible. [...]
> > |
> > | Therefore LTP test for more current features should be able to cope with older
> > | systems.
> > 
> > Also, (it's said[1]) perf, even though in kernel tree, is supposed to work
> > properly on any (older/newer) version of Linux.
> > 
> > Can you clarify this point in kselftest.rst?
> > 
> > I think, this would be useful for future kselftests developers, users,
> > and packagers. (Currently, I package for ALT Linux kselftests (and perf)
> > from the latest mainline branch, so people could test even older kernels
> > with the latest kselftests.
> > 
> > If there is policy to be backward-compatible kselftests in the future
> > could reach a state where users would run them in all pass mode (without
> > selecting only working tests). This, in turn, would increase [ease of]
> > usability of tests and thus frequency of their run and consequentially
> > quality kernel testing overall.
> > 
> 
> The policy is kselftests from new kernel can run on older kernels.
> Tests that don't meet dependencies and privileges to run are skipped.
> We do have newer tests that don't fail gracefully if dependencies aren't
> met and those cases are considered as bugs.
> 
> We have a wide range of tests in the suite. Some tests are at the
> granularity of a specific system call flag. It would be difficult to isolate
> all pass. What we can come close to is skipping tests that don't
> meet dependencies consistently and we strive to do this and consider the
> ones that don't meet as bugs and fix them.
> 
> Hope this gives you a context around backward compatibility.

Thanks much for the detailed explanation!

Vitaly,


      reply	other threads:[~2021-06-24 13:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-23 14:26 Kernel selftests and backward compatibility? Vitaly Chikunov
2021-06-23 18:08 ` Shuah Khan
2021-06-24 13:48   ` Vitaly Chikunov [this message]

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=20210624134847.zoms7776gm6d3q2k@altlinux.org \
    --to=vt@altlinux.org \
    --cc=ldv@altlinux.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=shuah@kernel.org \
    --cc=skhan@linuxfoundation.org \
    /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.