On Thu, Apr 21, 2022 at 01:41:20PM +0800, Zorro Lang wrote:
> On Wed, Apr 20, 2022 at 07:52:22PM +0200, Christian Brauner wrote:
> > Add a regression test for commit 705191b03d50 ("fs: fix acl translation").
> > This tests whether setting POSIX ACLs on a tmpfs mounted in a
> > non-initial user and mount namespace works as expected.
> >
> > Note, once again the idmapped mount testsuite is grossly misnamed at
> > this point. It has morphed into a full-blown generic vfs feature
> > testsuite.
Yup, and that's really important because this is the exact purpose
for which fstests exists: to cover every aspect of filesystem and
VFS functionality that needs test coverage.
> Hi,
>
> Good to know that, the idmapped-mounts things already been extended to 15k+
> lines[1] code, it's even much more than the unionmount-testsuite[2]. So I
> think it's time to think about shifting it from fstests/src to be an independent
> testsuit,
Please don't do that. That will mean the testing most fs developers
will get -zero- idmapped-mount test coverage and that's a major
issue. The kernel code that it covers is non trivial, has deep hooks
into every filesystem and these tests ensure that we filesystem
developers don't accidentally break it. It *needs* to be a part of
every filesystem developer's test environment, and we already have
that by having it integrated into fstests.
This is what we want - we want fstests to be the place that fs
developers add new tests to cover new functionality, and so all
filesystems get coverage of that functionality as part of the
development process.
This is exactly what we've spent the last 20 years building xfstests
into - it's gone from a filesystem specific tests suite to
supporting a dozen different filesystems and covers heaps of VFS
functionality as well.
As such, I think the last thing we want to be doing is telling
people to "take their code elsewhere". It sends the wrong message -
we want people to incorporate their complex test code into fstests
because that benefits every developer who uses fstests in their
daily workflow. The more test coverage we get, the better, and the
more test code we get integrated into fstests the better off we will
be.
> we can learn what 35c7a37928fd ("overlay: run unionmount testsuite test
> cases") did, maintain idmapped-mounts testsuite outside, then let fstests to be a
> wrapper to run it.
The unionmount tests suite was never a part of fstests like the
idmapped tests suite is. Very few developers know it exists, let
alone install it. Even fewer run it because it's part of the overlay
tests and almost nobody except overlay developers run overlay
testing...
-Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
