[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8F45F47C-86C0-472E-B701-001A4FF90DBC@oracle.com>
Date: Thu, 22 Jun 2023 16:58:08 +0000
From: Chuck Lever III <chuck.lever@...cle.com>
To: stsp <stsp2@...dex.ru>
CC: Jeff Layton <jlayton@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Al Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
Shuah Khan <shuah@...nel.org>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>
Subject: Re: [PATCH 2/2] selftests: add OFD lock tests
> On Jun 22, 2023, at 12:40 PM, stsp <stsp2@...dex.ru> wrote:
>
> 22.06.2023 16:48, Jeff Layton пишет:
>> I'm not opposed to adding a selftest here, but most filesystem testing
>> is done via xfstests:
>>
>> https://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git/
>>
>> It would be better to add this test to the existing generic/478 test
>> that tests OFD locks. Can you patch that to add a test for the new
>> functionality?
I agree with Jeff, this test needs to go in xfstests.
> I don't actually think its possible.
> It seems like their script creates 2
> t_ofd_locks processes, one for creating
> the lock, one for testing it.
> This is not our case.
> To make it work our way, we'd probably
> need to hack that test directly into
> t_ofd_locks.c, so that it can set and test
> from the same fd.
Or you could add a new test program.
> And I don't know how
> to even run these tests. :)
> So I am really inclined to limit myself
> with a kernel selftest.
IMO that's not a reason not to do this properly.
You should work with Jeff and the maintainer of
xfstests to make it happen.
--
Chuck Lever
Powered by blists - more mailing lists