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

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2021/7/21 上午9:11, Dave Chinner wrote:
> On Wed, Jul 21, 2021 at 06:34:16AM +0800, Qu Wenruo wrote:
>> I would no longer consider to upstream any simple debug purposed code.
>
> Qu, please stop behaving like a small child throwing a tantrum
> because they were told no.

Well, if you think so, go ahead, no one can change your mind anyway.

>
> If there's good reason to host debug code in the fstests repository,
> that's where it should go. See the patch I just posted that adds a
> dm-logwrites replay script to the tools/ directory:
>
> https://lore.kernel.org/fstests/20210721001333.2999103-1-david@fromorbit.com/T/#u
>
> This is really necessary to be able to analyse failures from tests
> that use dm-logwrites, and such a tool does not exist. Rather than
> requiring every developer that has to debug a dm-logwrites failure
> have to write their own replay tool, fstests should provide one.
>
> That's the whole point here.  I could be selfish and say "it's a
> debugging tool, I don't need to publish it because others can just
> write their own", but that ignores the fact it took me the best part
> of two days just to come up to speed on what dm-logwrites and
> generic/482 was doing before I could even begin to debug the
> failure.
>
> Requiring everyone to pass that high bar just to begin to debug a
> g/482 failure is not an effective use of community time and
> resources. The script I wrote embodies the main logwrites
> interactions I needed to reproduce and debug the issue, and I don't
> think anyone else should need to spend a couple of days of WTFing
> around the logwrites code just to be able to manually replay a
> failed g/482 test case. I've sunk that cost into a simple to use
> script and by pushing it into the fstests repository nobody else now
> needs to spend that time to write a manual replay script.
>
> If we apply that same logic to debugging hooks and the scripts that
> they run, then a hook script that is useful to one person for
> debugging a complex test is probably going to be useful to many more
> people. Hence if we are going to include hooks into the fstests
> infrastructure, we also need to consider including a method of
> curating a libary of hook scripts that people can just link into the
> hooks/ directory and start using with no development time at all.
>
> You need to stop thinking about debug code as "throw-away code".
> Debug code is just as important, if not more important, than the code
> that is being tested. As Brian Kernighan once said:
>
> 	"Debugging is twice as hard as writing the code in the first
> 	place. Therefore, if you write the code as cleverly as
> 	possible, you are, by definition, not smart enough to debug
> 	it."
>
> Put simply, anything we can do to lower the bar for debugging
> complex code exercised by complex tests is worth doing and *worth
> doing well*. Hooks can be a powerful debugging tool, but the
> introduction of such infrastructure needs more discussion and
> consideration than "here's a rudimetary start/end hook for one-off
> throw-away debug code".
>
> Most importantly, the discussion needs a much more constructive
> conversation than responding "No because I don't care about anyone
> else" to every suggestion or potential issue that is raised. Please
> try to be constructive and help move the discussion forward,
> otherwise the functionality you propose won't go anywhere largely
> because of your own behaviour rather than for unsovlable technical
> reasons...

I'm pretty clear about the hook I supposed, it's not for stable ABI or
complex framework, just a simple kit to make things a little easier.

The single purpose is just to make some throw-away debug setup simpler.

Whether debug tool should be throw-away is very debatable, and you're
pushing your narrative so much, that's very annoying already.

You can have your complex framework for your farm, I can also have my
simple setup running on RPI4.

I won't bother however you build your debug environment, nor you should.

Sometimes I already see the test setup of fstests too complex.
I totally understand it's for the portability and reproducibility, but
for certain debugs, I prefer to craft a small bash script with the core
contents copied from fstests, with all the complex probing/requirement,
which can always populate the ftrace buffer.


If you believe your philosophy that every test tool should be a complex
mess, you're free to do whatever you always do.

And I can always express my objection just like you.

So, you want to build a complex framework using the simple hook, I would
just say NO.

And you have made yourself clear that you want to make your debug setup
complex and stable, then I understand and just won't waste my time on
someone can't understand something KISS.

Thanks,
Qu

>
> Cheers,
>
> Dave.
>