Re: [PATCH 1/2] check: add a -smoketest option

[Zorro Lang <zlang@redhat.com>]

On Wed, Jul 26, 2023 at 02:01:02AM -0400, Theodore Ts'o wrote:
> On Tue, Jul 25, 2023 at 05:05:24PM -0700, Darrick J. Wong wrote:
> > 
> > If someone wants that, then ok.  The taret audience for this are the
> > drive-by filesystem patch authors.  IOWs, people who have some small bug
> > they want to try to fix and want to run a quick test to see if their
> > change works.
> 
> Zorro,
> 
> FYI, the context behind this was a comment I had made to Darrick that
> the time necessary to run "-g quick" had been getting longer and
> longer, and it might be nice to create a manually curated "-g smoke"
> that was good enough for drive-by patch authors.  I was originally
> thinking about a cut-down set of tests by selecting a subset of "-g
> quick", but Darrick suggested that instead, we just run a very small
> set of tests (mostly based on fsstress / fsx) and just run them in a
> loop for 4 minutes or so.
> 
> We also talked about having a time budget (say, 15 minutes) and then
> just dividing 15 time by the number of tests, and just run them in for
> a specified soak time, so that the total time is known ahead of time.
> 
> To be honest, I was a bit dubious it could be that simple, but that's
> where using kcov to show that you get a pretty good code coverage
> using something that simple comes from.
> 
> > I don't think it's reasonable to expect drive-by'ers to know all that
> > much about the fstests groups or spend the hours it takes to run -g all.
> > As a maintainer, I prefer that these folks have done at least a small
> > taste of QA before they start talking to the lists.
> 
> A big problem for the drive-by'ers is that that the top-level xfstests
> README file is just plain scary, and has far too many steps for a
> drive-by patch author to follow.
> 
> What I plan to add to a maintainer-entry-file.rst file for ext4 in the
> kernel docs is to tell that drive-by posters that should run
> "kvm-xfstests smoke" before submitting a patch, and setting up
> kvm-xfstess is dead simple easy:
> 
> 
> 1)  Install kvm-xfstests --- you only have to run this once
> 
> % git clone https://github.com/tytso/xfstests-bld fstests
> % cd fstests
> % make ; make install
> 
> # Optional, if your file system you are developing isn't ext4;
> # change f2fs to the file system of your choice
> % echo PRIMARY_FSTYPE=f2fs >> ~/.config/kvm-xfstests
> 
> 
> 2) Build the kernel suitable for use with kvm-xfstests
> 
> % cd /path/to/your/kernel
> % install-kconfig
> % kbuild
> 
> 3) Run the smoke test --- assuming the cwd is /path/to/your/kernel
> 
> (Note: today this runs -g quick, but it would be good if this could be
> faster)
> 
> % kvm-xfstests smoke 
> 
> 
> It's simple, and since the kvm-xfstests script will download a
> pre-compiled test appliance image automatically, there's no need to
> require the drive-by tester to figure out how compile xfstests with
> any of its prerequisites.
> 
> And once things are set up, then it's just a matter of running
> "kbuild" to build your kernel after you make changes, and running
> "kvm-xfstests smoke" to do a quick smoke testing run.
> 
> No muss, no fuss, no dirty dishes...   :-)

Hi Ted,

Thanks for this detailed explanation!

Ahaha, I'm just waiting for Darrick wake up, then ask him is there any
requirement/context about this patch. Due to he (looks like) a bit
hurry to push this patch :)

If most of you prefer this way (an ./check option, not a separated wrapper
script), I'm OK with that.

Just recently I'm a bit worry about the ./check code, it's becoming more
and more complex. I hope to separate something from it, but many things
entwined, and growing. Anyway that's another story, I'll look into this
patchset and review it soon.

Thanks,
Zorro

> 
> Cheers,
> 
> 					- Ted
>