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 >
