All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Eryu Guan <eguan@linux.alibaba.com>,
	Dave Chinner <david@fromorbit.com>, Qu Wenruo <wqu@suse.com>,
	fstests@vger.kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC] fstests: allow running custom hooks
Date: Tue, 20 Jul 2021 11:38:02 -0400	[thread overview]
Message-ID: <YPbt2ohi62VyWN7e@mit.edu> (raw)
In-Reply-To: <6b7699a9-fc5e-32d9-78c5-9c0e3cf92895@gmx.com>

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


  reply	other threads:[~2021-07-20 15:40 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-19  7:13 [PATCH RFC] fstests: allow running custom hooks Qu Wenruo
2021-07-19 14:02 ` Theodore Y. Ts'o
2021-07-19 22:06   ` Qu Wenruo
2021-07-20  0:43     ` Theodore Y. Ts'o
2021-07-20  0:50       ` Qu Wenruo
2021-07-20  4:05   ` Eryu Guan
2021-07-20  0:25 ` Dave Chinner
2021-07-20  0:36   ` Qu Wenruo
2021-07-20  2:14     ` Dave Chinner
2021-07-20  2:45       ` Qu Wenruo
2021-07-20  6:43         ` Dave Chinner
2021-07-20  7:26           ` Qu Wenruo
2021-07-20  7:57           ` Eryu Guan
2021-07-20  8:29             ` Qu Wenruo
2021-07-20  8:44               ` Qu Wenruo
2021-07-20 15:38                 ` Theodore Y. Ts'o [this message]
2021-07-20 22:34                   ` Qu Wenruo
2021-07-21  1:11                     ` Dave Chinner
2021-07-21  1:52                       ` Qu Wenruo
2021-07-21  2:23                         ` Damien Le Moal
2021-07-21  2:57                           ` Qu Wenruo
2021-07-21 23:28                           ` Dave Chinner
2021-07-22 14:41                             ` Theodore Ts'o
2021-07-22 22:21                               ` Dave Chinner
2021-07-23  3:30                                 ` Theodore Ts'o
2021-07-23  4:32                                 ` Eryu Guan
2021-07-20  1:16 ` Darrick J. Wong
2021-07-20  1:24   ` Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YPbt2ohi62VyWN7e@mit.edu \
    --to=tytso@mit.edu \
    --cc=david@fromorbit.com \
    --cc=eguan@linux.alibaba.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.