From: Daniel.Thibault@drdc-rddc.gc.ca (Thibault, Daniel)
Subject: [lttng-dev] [lttng-ust] [babeltrace] use case question -field names in event classes
Date: Wed, 12 Oct 2016 20:02:17 +0000 [thread overview]
Message-ID: <48CF5AC71E61DB46B70D0F388054EFFDB7DF191C@VAL-E-01.valcartier.drdc-rddc.gc.ca> (raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4280 bytes --]
----------------------------------------------------------------------
On Tue, Oct 11, 2016 at 4:46 PM, Staffan Tjernstrom <staffan at eternaltraveller.com> wrote:
> We have a situation where we have a significant number (1000's) of
> log-style trace messages generated by a large group of (sometime
> offsite) developers.
>
> Unfortunately the tracepoint definitions are maintained by a small
> group of central developers.
>
> So we have a need for generic tracepoint definitions, without losing
> the ability to tailor the output from individual log messages.
>
> One approach we've come up with involves including the labels as part
> of the parameter pack:
>
> TRACEPOINT_EVENT(
> my_app,
> two_ints_and_string,
> TP_ARGS(
> // some pre-amble fields removed for clarity
> char const *, label1_arg,
> int, value1_arg,
> char const *, label2_arg,
> int, value2_arg,
> char const *, label3_arg,
> char const *, value3_arg
> ),
> TP_FIELDS(
> // pre-amble removed for clarity
> ctf_string( label1, label1_arg )
> ctf_integer(int, value1, value1_arg)
> ctf_string( label2, label2_arg )
> ctf_integer(int, value2, value2_arg)
> )
> )
>
> and we can then call this from multiple locations in our general
> code-base using:
>
> tracepoint(my_app, two_ints_and_string, "widget_height", 19,
> "widget_width", 23, "widget_name", widget_name_as_cstring);
>
> tracepoint(my_app, two_ints_and_string, "x_coordinate", x,
> "y_coordinate", y, "point_type", "star");
>
> The issue with this is that the output obviously treats the field
> names and their values as individual items, so we get output like
>
> label1 = "widget_height", value1 = 19, label2 = "widget_width", value2
> =- 23, label3 = "widget_name", value3 = "topper"
> label1 = "x_coordinate", value1 = -23, label2 = "y_coordinate", value2
> = 25532, label3 = "point_type", value3 = "star"
>
> But of course we need to mechanically scrape / inspect the output, so
> what we'd really like would be output something more like:
>
> widget_height = 19, widget_width = 23, widget_name = "topper"
> x_coordinate = -23, y_coordinate = 25532, point_type = "star"
>
> Post-processing of the babeltrace output is of course one option
> (using -n none), but it feels like the wrong choice (adding more steps
> to the tracing chain).
>
> Does anyone out there have any better ideas how to achieve having our
> cake ( a small number of generic tracepoints ), and eating it (
> user-defined field names )?
Have you thought about using TRACEPOINT_EVENT_CLASS and TRACEPOINT_EVENT_INSTANCE?
Untested:
TRACEPOINT_EVENT_CLASS(
my_app,
two_ints_and_string,
TP_ARGS(
// some pre-amble fields removed for clarity
int, value1_arg,
int, value2_arg,
char const *, value3_arg
),
TRACEPOINT_EVENT_INSTANCE(
my_app,
two_ints_and_string,
two_ints_and_string_widget,
TP_ARGS(
// repeats the TRACEPOINT_EVENT_CLASS TP_ARGS
),
TRACEPOINT_EVENT_INSTANCE(
my_app,
two_ints_and_string,
two_ints_and_string_point,
TP_ARGS(
// repeats the TRACEPOINT_EVENT_CLASS TP_ARGS
),
tracepoint(my_app, two_ints_and_string_widget, 19, 23, widget_name_as_cstring);
tracepoint(my_app, two_ints_and_string_point, x, y, "star");
You would only need one TRACEPOINT_EVENT_CLASS per signature, and could tailor the event names to make the arguments as obvious as they need to be.
Daniel U. Thibault, M.Sc.²
Informaticien scientifique, CME-PSC, Centre de recherches de Valcartier
Recherche et développement pour la défense Canada / Gouvernement du Canada
daniel.thibault at drdc-rddc.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538
daniel.thibault at forces.gc.ca / Tél: 418-844-4000x4245 Téléc: 418-844-4538
Computer Scientist, MCCS-SPC, Valcartier Research Centre
Defence Research and Development Canada / Government of Canada
daniel.thibault at drdc-rddc.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538
daniel.thibault at forces.gc.ca / Tel: 418-844-4000x4245 Fax: 418-844-4538
DRDC is an agency of the Department of National Defence / RDDC est une agence du ministère de la Défense nationale
reply other threads:[~2016-10-12 20:02 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48CF5AC71E61DB46B70D0F388054EFFDB7DF191C@VAL-E-01.valcartier.drdc-rddc.gc.ca \
--to=daniel.thibault@drdc-rddc.gc.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox