lttng-dev.lists.lttng.org archive mirror
 help / color / mirror / Atom feed
From: Philippe Proulx via lttng-dev <lttng-dev@lists.lttng.org>
To: "Owen, Mark (US)" <Mark.Owen@flir.com>
Cc: "lttng-dev@lists.lttng.org" <lttng-dev@lists.lttng.org>
Subject: Re: [lttng-dev] [barectf] Filter trace messages based on log level
Date: Tue, 6 Oct 2020 10:45:02 -0400	[thread overview]
Message-ID: <CAB4xu_2A_7RXxG_mJ7fdzSHAP2CrH96yKW0Lkf=DZwf24X8JMA@mail.gmail.com> (raw)
In-Reply-To: <1601988739.4352.32.camel@flir.com>

On Tue, Oct 6, 2020 at 9:16 AM Owen, Mark (US) via lttng-dev
<lttng-dev@lists.lttng.org> wrote:
>
> Hi,
>
> Thank you for your work on barectf!

Thank you for writing, Mark.

I always appreciate getting feedback regarding 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.

barectf seems like a good fit indeed.

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

barectf doesn't directly support dynamic event record filtering
currently.

The current role of a barectf platform is to write closed CTF packets to
some back end (async serial in your case), so this is not where you
would deal with event record filtering at the moment.

Here are two suggestions:

1. Wrap the generated barectf tracing functions at your application
   level to augment them with logging-level-based filtering.

   You can probably do this with preprocessor macros.

2. We can add some dynamic event record filtering feature to the
   upstream barectf project.

   I don't have the details, but, for each tracing function, a callback
   function (part of the platform, maybe) would be called to accept or
   reject the event record.

   EfficiOS offers development services which can help here;
   see <https://www.efficios.com/contact/>.

Hope this helps!

Philippe

>
> 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
_______________________________________________
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 14:45 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
2020-10-06 14:45 ` Philippe Proulx via lttng-dev [this message]

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='CAB4xu_2A_7RXxG_mJ7fdzSHAP2CrH96yKW0Lkf=DZwf24X8JMA@mail.gmail.com' \
    --to=lttng-dev@lists.lttng.org \
    --cc=Mark.Owen@flir.com \
    --cc=eeppeliteloop@gmail.com \
    --subject='Re: [lttng-dev] [barectf] Filter trace messages based on log level' \
    /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

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