On Tue, Jul 20, 2021 at 04:44:29PM +0800, Qu Wenruo wrote: > Anyway, if building a stable and complex API just for hooks, then it's > completely against my initial purpose. So you said you are only using this for debugging purposes; at least in my workflow, when I'm trying to debug a particular test case, I'm *only* run a single test. So today, the way I handle this is to run hook scripts in the gce-xfstests framework before and after running the check script. It does mean that there is excess work which gets traced from the check script setting up and cleaning up, but it's mainly been good enough for me. It would be slightly nicer if there was a way to start and stop various debugging hooks (e.g., starting and stopping traces, clearing and grabing the lock_Stat info), etc.,) jut before and starting the test. But it was never important to me to propose changes to the upstream xfstests. In answer to the question which Darrick and Dave asked, yes, I could do this via the exclude list. It just seemed that if we're going to add a programmtic hook, maybe it would make sense to do it via the hook script. It is true that there are ways to do this, though, although there is a difference to a static excldue list that has to get created for all tests that might be run, versus hook script that is run for each test. <Shrug> There are other ways of doing things; the question is whether the hook script approach is sufficiently better that it's worth getting something like this upstream. It may be that keeping things like this in each developer's own private test runner is the right thing. I have "gce-xfstests --hooks <hookdir>" for my own use, and have had it for years. Cheers, - Ted
