Re: [PATCH][RFC] tracing: Enable tracepoints via module parameters

[Dan Williams]

On Tue, Apr 20, 2021 at 5:55 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
[..]
> > > So yes, function tracing now allows setting a filter to trace only the
> > > functions for a given module, and if that module is not yet loaded, it
> > > stores the filter until it is.
> >
> > Ah, thanks for the pointer. So if I wanted to convert a kernel command like:
> >
> > libnvdimm.dyndbg
> >
> > ...it would be something like:
> >
> > ftrace=function ftrace_filter=:mod:libnvdimm
>
> Hmm, that may not work, but if it doesn't, it would be trivial to add it.
>
> >
> > ...and then "cat /sys/kernel/tracing/trace" instead of "dmesg" to
> > retrieve... assuming only "got here" style debug was being attempted.
> >
> > > To do something similar for tracepoints, I think we still need to add it as
> > > a module parameter.
> >
> > The dev_dbg() filter language is attractive, it's too bad
>
> Not sure what you mean by that. What filter language. Tracepoints do have a
> pretty good filtering too.

I'm trying to replicate dev_dbg() usability with tracing. So, when
people say "don't use dev_dbg() for that" that tracing can reliably
replace everything that dev_dbg() was offering. What I think that
looks like is the ability to turn on function tracing by a function
name glob in addition to any tracepoints in those same functions all
from the kernel boot command line, or a module parameter.

> > trace_printk() has such a high runtime cost as combining dynamic-debug
> > and tracing would seem to be a panacea.
>
> trace_printk() has a high runtime cost? Besides that it's not allowed on
> production code (see nasty banner), it is made to be extremely fast.
> Although, it does do sprintf() work.

I was referring to the banner. dev_dbg() does not have that production
code restriction.

> Would adding automatic module parameters be an issue? That is, you can add
> in the insmod command line a parameter that will enable tracepoints. We
> could have a way to even see them from the modinfo. I think I had that
> working once, and it wasn't really that hard to do.

Yeah, that's what you seemed to have working at the beginning of this thread:

https://lore.kernel.org/lkml/1299622684.20306.77.camel@xxxxxxxxxxxxxxxxxxx/