[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aa0bbfeec78bc90966e660af91eb39acccb77d73.camel@redhat.com>
Date: Tue, 21 Oct 2025 10:58:06 -0500
From: Crystal Wood <crwood@...hat.com>
To: Tomas Glozar <tglozar@...hat.com>
Cc: Steven Rostedt <rostedt@...dmis.org>, LKML
<linux-kernel@...r.kernel.org>, Linux Trace Kernel
<linux-trace-kernel@...r.kernel.org>, John Kacur <jkacur@...hat.com>, Luis
Goncalves <lgoncalv@...hat.com>, Costa Shulyupin <costa.shul@...hat.com>,
Wander Lairson Costa <wander@...hat.com>, Arnaldo Carvalho de Melo
<acme@...nel.org>
Subject: Re: [PATCH 3/4] rtla/timerlat: Add example for BPF action program
On Tue, 2025-10-21 at 16:54 +0200, Tomas Glozar wrote:
> po 20. 10. 2025 v 19:53 odesÃlatel Crystal Wood <crwood@...hat.com> napsal:
> >
> > We should have the makefile build this, and add a test that uses it.
> >
>
> I agree. I tried to use the example, but it would be also good to
> check if the BPF program was actually executed.
>
> That is hard to do reliably for the current example, as it writes into
> the global tracefs instance, which might conflict with another user of
> the same instance. I will write another BPF program that will create a
> map instead, and a script that will check the map value via
> --on-threshold in the test.
Huh, so I guess BPF is an exception to the "no generic printk to the
global trace instance except for debugging that generates a big boot
splat" rule?
Speaking of which, why doesn't trace_osnoise.c call
trace_array_init_printk() given that it uses trace_array_printk_buf()?
-Crystal
Powered by blists - more mailing lists