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

[Qu Wenruo <wqu@suse.com>]

On 2021/7/21 上午10:23, Damien Le Moal wrote:
>>
>> 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.
> 
> I think that Dave's opinion is actually the reverse of this: hooks, if well
> designed, can be useful and facilitate adding functionalities to a complex test
> framework. And sure, the hook infrastructure implementation can in itself be
> complex, but if well designed, its use can be, and should be, very simple.

In fact, if we really integrate the hook into the fstests to the 
standard of Dave, I doubt it can be that simple ever.

E.g. if the hook is going to inherit all the fstests shell macros, from 
_not_run() to various _require_*, then it's completely the opposite what 
I want, and it's not going to be simpler than writing a proper test case.

What I original want is so simple that for start hook, it only accepts 
one parameter (for the sequence number), one environment variable (for 
the temporary path).

That's the level of simplicity I want, no complex calls/probes just a 
proper test case.


Yes, a well designed hook can do that without problem, as it will be 
superset of the simple hook.

But then when one is going to do complex things, and reading the doc, it 
will be way more complex than the original purpose.
And I hate to even have such possibility to be complex.

Ironically not to mention the maintaining effort involved. E.g. if the 
hook is going to inherit those shell variables/macors, then any changing 
in the fstests itself will affect the hooks, no matter if there is any 
real users of such complex thing.

> 
> Implementation is done once. The complexity at that stage matters much less than
> the end result usability. As a general principle, the more time one put in
> design and development, the better the end result. Here, that means hooks being
> useful, flexible, extensible, and reusable.

Hard to say.

I still can't yet get used to the preamble change introduced recently.
(The group list not properly updated)

And it's pretty clear it won't be the last change of the fstest 
infrastructure.

Hook won't be more stable than fstests itself, and it will take time to 
maintain, no matter if there is really users for it.

> 
> And one of the functionality of the hook setup could be "temporary, external
> hook" for some very special case debugging as you seem to need that. What you
> want to do and what Dave is proposing are not mutually exclusive.

Yeah, it's a subset in theory.

But then that's completely unrelated to my initial purpose.

I won't object if someone is willing to do that separately, and may be 
even happy if a such dedicated, simple hook can be provided without 
reading the complex doc/design of the framework.

But putting tons of unrelated things into an originally simple purpose, no.

Please do that in a separate patch/thread for the complex hook framework 
then.

Thanks,
Qu

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