[lttng-dev] [barectf] Filter trace messages based on log level

[Philippe Proulx]

On Tue, Oct 6, 2020 at 9:16 AM Owen, Mark (US) via lttng-dev
<lttng-dev at 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 at lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev