All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
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: Wed, 21 Jul 2021 06:34:16 +0800	[thread overview]
Message-ID: <f37bec82-85cd-b818-8691-6c047751c4a6@gmx.com> (raw)
In-Reply-To: <YPbt2ohi62VyWN7e@mit.edu>



On 2021/7/20 下午11:38, Theodore Y. Ts'o wrote:
> 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.

Under most case, yes, and that's also what I usually do.

But I have seen some strange case which doesn't trigger error by itself,
but needs some other tests to be run before the triggering one.

>  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.

 From the feedback, I guess that's the case.
I would no longer consider to upstream any simple debug purposed code.

Thanks,
Qu
>
> 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 22:35 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
2021-07-20 22:34                   ` Qu Wenruo [this message]
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=f37bec82-85cd-b818-8691-6c047751c4a6@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=david@fromorbit.com \
    --cc=eguan@linux.alibaba.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=tytso@mit.edu \
    --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.