lkml.org 
[lkml]   [2021]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 1/4] tracing: add error_report trace points
On Wed, Jan 13, 2021 at 10:10 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Wed, 13 Jan 2021 10:16:54 +0100
> Alexander Potapenko <glider@google.com> wrote:
>
> > +DECLARE_EVENT_CLASS(error_report_template,
> > + TP_PROTO(const char *error_detector, unsigned long id),
>
> Instead of having a random string, as this should be used by a small finite
> set of subsystems, why not make the above into an enum?

You're probably right.
I just thought it might be a good idea to minimize the effort needed
from tools' authors to add these tracepoints to the tools (see the
following two patches), and leave room for some extensibility (e.g.
passing bug type together with the tool name etc.)

> > + TP_ARGS(error_detector, id),
> > + TP_STRUCT__entry(__field(const char *, error_detector)
> > + __field(unsigned long, id)),
> > + TP_fast_assign(__entry->error_detector = error_detector;
> > + __entry->id = id;),
> > + TP_printk("[%s] %lx", __entry->error_detector,
>
> Then the [%s] portion of this could also be just a __print_symbolic().

We'll need to explicitly list the enum values once again in
__print_symbolic(), right? E.g.:

enum debugging_tool {
TOOL_KFENCE,
TOOL_KASAN,
...
}

TP_printk(__print_symbolic(__entry->error_detector, TOOL_KFENCE,
TOOL_KASAN, ...),

\
 
 \ /
  Last update: 2021-01-14 08:52    [W:0.067 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site