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@xxxxxxxxxxxxx/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.
