Re: [PATCH 6/8] fstests: consolidate no cleanup test setup

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]



On Tue, May 24, 2022 at 03:22:45PM +0300, Amir Goldstein wrote:
> On Tue, May 24, 2022 at 2:42 PM Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> >
> > From: Dave Chinner <dchinner@xxxxxxxxxx>
> >
> > Many of the XFS fuzzer tests define a "no cleanup" cleanup function.
> > Consolidate this in common/preamble and deduplicate all the tests
> > using this setup.
> >
> > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
> > ---
> >  common/preamble | 9 +++++++++
> >  tests/xfs/083   | 5 -----
> >  tests/xfs/085   | 5 -----
> >  tests/xfs/086   | 5 -----
> >  tests/xfs/087   | 5 -----
> >  tests/xfs/088   | 5 -----
> >  tests/xfs/089   | 5 -----
> >  tests/xfs/091   | 5 -----
> >  tests/xfs/093   | 5 -----
> >  tests/xfs/097   | 5 -----
> >  tests/xfs/098   | 5 -----
> >  tests/xfs/099   | 5 -----
> >  tests/xfs/100   | 5 -----
> >  tests/xfs/101   | 5 -----
> >  tests/xfs/102   | 5 -----
> >  tests/xfs/105   | 5 -----
> >  tests/xfs/112   | 5 -----
> >  tests/xfs/113   | 5 -----
> >  tests/xfs/117   | 5 -----
> >  tests/xfs/120   | 5 -----
> >  tests/xfs/123   | 5 -----
> >  tests/xfs/124   | 5 -----
> >  tests/xfs/125   | 5 -----
> >  tests/xfs/126   | 5 -----
> >  tests/xfs/130   | 5 -----
> >  25 files changed, 9 insertions(+), 120 deletions(-)
> >
> 
> I propose to use a dedicated helper _unregister_cleanup to opt out
> of _cleanup and still leave _cleanup implicit for all the rest of the tests,
> but I will not stop merging this cleanup on account of this suggestion.
> It could be done by a followup cleanup as well, so unless you want to
> take my suggestion

Cart before the horse.  There's another 1000 tests I haven't even
looked at yet, and there's still a heap of work to derive
commonality from the remaining 100 xfs tests that have a random
assortment of loop, local, dm, etc cleanup functions.

I'm trying to focus on cleaning up and deduplicating the tests, not
whether there's an exactly optimal API for a specific cleanup
function. Once everything is deduplicated, changing the cleanup API
is a much, much simpler proposition. So that's the first prioirty
and trivialities like "_register_cleanup _no_cleanup" vs
"_unregister_cleanup" aren't even on my radar.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx



[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux