From: "Owen, Mark \(US\) via lttng-dev" <lttng-dev@lists.lttng.org>
To: "lttng-dev@lists.lttng.org" <lttng-dev@lists.lttng.org>
Subject: [lttng-dev] [barectf] Filter trace messages based on log level
Date: Tue, 6 Oct 2020 12:59:57 +0000 [thread overview]
Message-ID: <1601988739.4352.32.camel@flir.com> (raw)
Hi,
Thank you for your work on barectf!
I'm considering using it with our embedded MCUs that run on bare metal in
conjunction with other devices running embedded Linux. The barectf platform back
end would primarily be async serial that would be consumed by a device running
embedded Linux.
Our current home brew trace implementation is limited to a logging a log level
and a message string. I see great potential in being able to use the CTF format
to output much more information when events occur than just a level and a
string. My primary concern with barectf is that our current trace implementation
allows us to filter out packets based on log level. I believe this will be
necessary for us not to exceed our bandwidth limitation (the serial port may
also need to be shared for telemetry and command messaging).
My question is, do you think barectf is a good fit for filtering packets based
on a logging level? If so, where would you suggest implementing said filtering
(e.g. extending the platform API or use a custom API in the specific platform
implementation)?
I see that the platform API supports enabling or disabling tracing but I am
looking for something more granular. Is this something that make sense to be
implemented in the platform implementation? My initial thought is that we would
probably need to extend our barectf platform, back end implementation to include
methods for setting the logging filter level.
Before I moved forward I wanted to get your input. Any guidance you could
provide here would be very helpful.
Thank you,
Mark Owen
________________________________
Notice to recipient: This email is meant for only the intended recipient of the transmission, and may be a communication privileged by law, subject to export control restrictions or that otherwise contains proprietary information. If you receive this email by mistake, please notify us immediately by replying to this message and then destroy it and do not review, disclose, copy or distribute it. Thank you in advance for your cooperation.
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
next reply other threads:[~2020-10-06 13:16 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-06 12:59 Owen, Mark (US) via lttng-dev [this message]
2020-10-06 14:45 ` [lttng-dev] [barectf] Filter trace messages based on log level Philippe Proulx via lttng-dev
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=1601988739.4352.32.camel@flir.com \
--to=lttng-dev@lists.lttng.org \
--cc=Mark.Owen@flir.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;
as well as URLs for NNTP newsgroup(s).