Re: [PATCH v2] fstests: add basic ftrace support

[Dave Chinner <david@fromorbit.com>]

On Fri, Jun 04, 2021 at 10:45:52AM +0800, Qu Wenruo wrote:
> > So how does one enable all 500+ xfs tracepoints for this? Or just
> > some subset? i.e. how do we pass it a list of events like we do
> > trace-cmd?  IOWs, for this to be actually useful as a replacement
> > for trace-cmd, it has to be able to replace invocations like this:
> > 
> > # trace-cmd record -e xfs_i*lock* -e xfs_buf* -e printk -e iomap* ....
> 
> That's not a big problem, you can do the same thing just using tracefs
> interface, without invovling trace-cmd at all.
> 
> For your above case, you can do the same thing without trace_cmd at all:
> 
> # cat ${tracefs}/available_events | grep xfs_i*lock >> \
>   ${tracefs}/set_event
> # cat ${tracefs}/available_events | grep xfs_buf* >> \
>   ${tracefs}/set_event
> # cat ${tracefs}/available_events | grep iomap* >> \
>   ${tracefs}/set_event
> # cat ${tracefs}/available_events | grep printk >> \
>   ${tracefs}/set_event

....

You forgot that now I have to turn all the events off again
manually. And if the script crashes and doesn't clean up, then I've
got to do that manually.

Talk about going back to the dark ages....

> I mean, if you can use trace-cmd, I see now reason you can't pack your trace
> events into a small script to enable it before running the tests.

The whole point of using tools like perf and trace-cmd is so we
don't need to know how the underlying mechanisms work, and we don't
have to relearn this crap every time the developers decide they are
going to change how it works.

> Or is trace-cmd really making us forget how to manually setup ftrace
> evetnts?

You have got to be joking, right?

The whole point of trace-cmd and perf existing is so that nobody
except the developers of those tools need to know how the complex,
obscure, whacky low level kernel interfaces work. Nor do people have
to keep up with how they change from kernel to kernel, because the
tools abstract all this bullshit away from the user.

I forgot about that interface when trace-cmd was first written
(2009, IIRC). IOWs, I haven't used the low level tracing interfaces
at all for over a decade because it's an utter PITA to use.

Can you imaging saying to another developer "we don't need a mkfs
command because I can write the structures direct to the block
device myself!". It doesn't make much sense, does it? Yet that's
pretty much exactly what you are saying here....

So, no, I don't think poking at low level tracing interfaces inside
fstests is a good idea, especially as it also requires wrapping
fstests in more scripts to control it. Just use trace-cmd to control
trace recording like everyone else already does.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com