lttng-dev.lists.lttng.org archive mirror
 help / color / mirror / Atom feed
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

             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).