Re: [PATCH RFC] fstests: allow running custom hooks

From: Dave Chinner <david@fromorbit.com>
To: Qu Wenruo <wqu@suse.com>
Cc: fstests@vger.kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH RFC] fstests: allow running custom hooks
Date: Tue, 20 Jul 2021 10:25:36 +1000	[thread overview]
Message-ID: <20210720002536.GA2031856@dread.disaster.area> (raw)
In-Reply-To: <20210719071337.217501-1-wqu@suse.com>

On Mon, Jul 19, 2021 at 03:13:37PM +0800, Qu Wenruo wrote:
> This patch will allow fstests to run custom hooks before and after each
> test case.
> 
> These hooks will need to follow requirements:
> 
> - Both hook files needs to be executable
>   Or they will just be ignored
> 
> - Stderr and stdout will be redirected to "$seqres.full"
>   With extra separator to distinguish the hook output with real
>   test output
> 
>   Thus if any of the hook is specified, all tests will generate
>   "$seqres.full" which may increase the disk usage for results.
> 
> - Error in hooks script will be ignored completely
> 
> - Environment variable "$HOOK_TEMP" will be exported for both hooks
>   And the variable will be ensured not to change for both hooks.
> 
>   Thus it's possible to store temporary values between the two hooks,
>   like pid.
> 
> - Start hook has only one parameter passed in
>   $1 is "$seq" from "check" script. The content will the path of current
>   test case. E.g "tests/btrfs/001"
> 
> - End hook has two parameters passed in
>   $1 is the same as start hook.
>   $2 is the return value of the test case.
>   NOTE: $2 doesn't take later golden output mismatch check nor dmesg/kmemleak
>   check.
> 
> For more info, please refer to "README.hooks".

This is all info that should be in README.hooks, not in the commit
message.  Commit messages are about explaining why something needs
to exist or be changed, not to describe the change being made. This
commit message doesn't tell me anything about what this is for, so I
can't really make any value judgement on it - exactly what is this
intended to be used for?

FWIW, if a test needs something to be run before/after the test, it
really should be in the test, run as part of the test. Adding
overhead to every test being just to check for something that
doesn't actually have a defined use, nor will exist or be used on
the vast majority of systems running fstests doesn't seem like the
best idea to me.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com