From: Dave Chinner <david@fromorbit.com>
To: stsp <stsp2@yandex.ru>
Cc: Chuck Lever III <chuck.lever@oracle.com>,
Jeff Layton <jlayton@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Shuah Khan <shuah@kernel.org>,
"linux-kselftest@vger.kernel.org"
<linux-kselftest@vger.kernel.org>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>
Subject: Re: [PATCH 2/2] selftests: add OFD lock tests
Date: Fri, 23 Jun 2023 08:15:45 +1000 [thread overview]
Message-ID: <ZJTIEaqwkc1U050E@dread.disaster.area> (raw)
In-Reply-To: <4582a51d-2b29-f430-2f8f-ed1239d70f70@yandex.ru>
On Thu, Jun 22, 2023 at 10:31:06PM +0500, stsp wrote:
>
> 22.06.2023 22:12, Chuck Lever III пишет:
> > I don't have a strong preference. A good choice is to
> > push the test before the kernel changes are merged.
> It will fail though w/o kernel changes.
> So what exactly is the policy?
filesystem unit test functionality needs to be pushed into fstests
and/or ltp. The preference is the former, because just about every
filesystem developer and distro QA team is running this as part of
their every-day testing workflow.
fstests is written to probe whether the kernel supports a given
feature or not before testing it. It will _not_run() a test that
doesn't have the required kernel/fs/device support, and this is not
considered a test failure.
Yes, it means you have to also write the userspace feature probing
code, but that should be trivial to do because userspace already has
to be able to safely discover that this extension exists, right?
-Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2023-06-22 22:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-21 15:22 [PATCH 0/2] v2: F_OFD_GETLK extension to read lock info Stas Sergeev
2023-06-21 15:22 ` [PATCH 1/2] fs/locks: F_UNLCK extension for F_OFD_GETLK Stas Sergeev
2023-06-21 15:22 ` [PATCH 2/2] selftests: add OFD lock tests Stas Sergeev
2023-06-22 11:48 ` Jeff Layton
2023-06-22 16:40 ` stsp
2023-06-22 16:58 ` Chuck Lever III
2023-06-22 17:05 ` stsp
2023-06-22 17:12 ` Chuck Lever III
2023-06-22 17:31 ` stsp
2023-06-22 22:15 ` Dave Chinner [this message]
2023-06-22 17:34 ` Frank Filz
2023-08-09 7:56 ` stsp
2023-06-22 16:54 ` stsp
2023-06-21 15:22 ` [PATCH] fcntl.2: document F_UNLCK F_OFD_GETLK extension Stas Sergeev
2023-06-22 12:03 ` Jeff Layton
2023-06-23 10:07 ` stsp
-- strict thread matches above, loose matches on Subject: below --
2023-06-22 16:52 [PATCH 0/2] v3: F_OFD_GETLK extension to read lock info Stas Sergeev
2023-06-22 16:52 ` [PATCH 2/2] selftests: add OFD lock tests Stas Sergeev
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=ZJTIEaqwkc1U050E@dread.disaster.area \
--to=david@fromorbit.com \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=stsp2@yandex.ru \
--cc=viro@zeniv.linux.org.uk \
/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