From: bcruickshank@ti.com (Cruickshank, Brian)
Subject: [ltt-dev] [RFC] New UST 2.0 Tracepoint Event API : TRACEPOINT_FORMAT
Date: Thu, 1 Sep 2011 14:25:43 +0000 [thread overview]
Message-ID: <F52E64FB055A36449A17C8EBA7B30C8001E86F@DLEE01.ent.ti.com> (raw)
In-Reply-To: <20110831163639.GA12439@Krystal>
Hi Mathieu,
I think the addition of per-tracepoint format strings and the addition of "loglevel" information to the tracepoint API would both be very helpful as it will make it easier to migrate from and integrate with many existing software instrumentation APIs.
How would the %s format specifier in the format string be handled? E.g. would its use be restricted to referencing constant strings (i.e. where the field associated with the %s specifier would be logged as an integer value containing the address of the string, which the host-side software would be able to use to look up the text associated with the string by reading the metadata or the ELF file for the application) or is the intent to support dynamically allocated strings of arbitrary length (e.g. by rendering the string on the target before logging the event)?
Regards,
Brian Cruickshank
Texas Instruments
-----Original Message-----
From: Mathieu Desnoyers [mailto:mathieu.desnoyers@efficios.com]
Sent: Wednesday, August 31, 2011 12:37 PM
To: ltt-dev at lists.casi.polymtl.ca; Nils Carlson
Subject: [ltt-dev] [RFC] New UST 2.0 Tracepoint Event API : TRACEPOINT_FORMAT
Hi,
I've been informed that support for a per-tracepoint format string would
be welcomed by many. I would prefer not to make formats strings a
requirement, but rather an optional feature. I am considering the
following API:
TRACEPOINT_FORMAT(tracepoint_name,
"text describing a format string with args like %s and also %d",
fieldname_1, fieldname_2)
where fieldname_* refer to the name of the fields declared in the
tracepoint (NOT the tracepoint arguments!).
e.g.
TRACEPOINT_EVENT(ust_tests_hello_tptest,
TP_PROTO(int anint, long along, char *text)
TP_ARGS(anint, along, text)
TP_FIELDS(
ctf_integer(int, intfield, anint)
ctf_integer(long, longfield, along)
ctf_string(stringfield, text)
)
)
TRACEPOINT_FORMAT(tracepoint_name,
"some message %d and more %s",
intfield, stringfield)
Having some level of automated compiler-level type checking for the
format string in there might be a nice to have, but might be rather
tricky, and could change the API slightly as I proceed to the
implementation.
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
ltt-dev mailing list
ltt-dev at lists.casi.polymtl.ca
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
next prev parent reply other threads:[~2011-09-01 14:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-31 16:36 Mathieu Desnoyers
2011-09-01 14:25 ` Cruickshank, Brian [this message]
2011-09-01 17:33 ` Mathieu Desnoyers
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=F52E64FB055A36449A17C8EBA7B30C8001E86F@DLEE01.ent.ti.com \
--to=bcruickshank@ti.com \
/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