On Fri, Jul 23, 2021 at 08:21:50AM +1000, Dave Chinner wrote: > On Thu, Jul 22, 2021 at 10:41:29AM -0400, Theodore Ts'o wrote: > > On Thu, Jul 22, 2021 at 09:28:30AM +1000, Dave Chinner wrote: > > > > > > I'm thinking that it is something relatively simple like this: > > > > > > fstests/tests/hooks > > > - directory containing library of hook scripts > > > > I'd suggest fstests/common/hooks instead, since the hook scripts > > aren't actually *tests* per so, but rather utility scripts, and common > > would be a better place for it, I think. Agreed, then we could avoid naming hooks dir as "Hooks". > > True, but I don't think common/ is the right place, either, because > that's for common test infrastructure. I only just looked, but > there's a lib/ directory in fstests. lib/hooks seems like the right > place for this, and if I had of looked yesterday I would have put it > there from the start. :/ > > Is that an acceptible location? Right now the lib dir contains mainly c libs used by test binaries, it looks like part of the build infrastructure to me. OTOH, I think common/hooks is fine, as hooks is part of the test harness to me. Or maybe tools/hooks is another choice? Thanks, Eryu > > > > fstests/hooks/ > > > - directory containing symlinks to hook scripts > > > > This might be a good default, but it might be better if the location > > of the hook directory could be overridden via an environment variable. > > In some cases, instead of having run-time configuration inside the > > fstests directtory with .gitignore, it might be more convenient for it > > if were made available externally (for example, via a 9p file system > > in a case where tests are being run via KVM using a rootfs test image > > with qmeu's snapshot mode so the hook directory could be supplied from > > the host). > > Yup, that's easy enough to do. We can do it exactly the same way we > allow RESULT_BASE to point the results to a user defined directory. > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx
