Re: [PATCH v1] dynamic_debug: add support for logs destination

[jim . cromie]

On Tue, Oct 3, 2023 at 1:57 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> On Mon, 2 Oct 2023 14:49:20 -0600
> jim.cromie@xxxxxxxxx wrote:
>
> > hi Lukasz,
> >
> > sorry my kernel-time has been in my own trees.
> >
> > What I dont understand is why +T is insufficient.
> >
> > IIUC, tracefs is intended for production use.
> > thats why each event can be enabled / disabled
> > - to select and minimize whats traced, and not impact the system
> >
> > and +T  can forward all pr_debugs to trace,
> > (by 1-few trace events defined similarly to others)
> > or very few, giving yet another selection mechanism
> > to choose or eliminate specific pr-debugs and reduce traffic to
> > interesting stuff.
> >
> > Once your debug is in the trace-buf,
> > shouldnt user-space be deciding what to do with it ?
> > a smart daemon could leverage tracefs to good effect.
> >
> > IMO the main value of +T is that it allows feeding existing pr_debugs
> > into the place where other trace-data is already integrated and managed.
> >
> > At this point, I dont see any extra destination handling as prudent.
> >
>
>
> I'm fine with either approach. I kind of like the creation of the instance,
> as that allows the user to keep this debug separate from other tracing
> going on. We are starting to have multiple applications using the tracing
> buffer (although most are using instances, which is why I'm trying to make
> them lighter weight with the eventfs code).
>
> -- Steve
>


Ok Im starting to grasp that multiple instances are good
(and wondering how I didnt notice)

What doesnt thrill me is the new _ddebug field, it enlarges the footprint.

can you make it go away ?
I have some thoughts ..