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... :-) Cheers, - Ted
