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.
