Re: [PATCH 00/15] tracepoint: Avoid double static_branch evaluation at guarded call sites
Vineeth Remanan Pillai <[email protected]> Thu, 12 Mar 2026 12:08:49 -0400
| Newsgroups | org.kernel.vger.linux-sctp,org.freedesktop.lists.amd-gfx,org.freedesktop.lists.dri-devel,org.kernel.vger.bpf,org.kernel.vger.io-uring,org.kernel.vger.linux-btrfs,org.kernel.vger.linux-i2c,org.kernel.vger.linux-input,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pm,org.kernel.vger.linux-scsi,org.kernel.vger.linux-spi,org.kernel.vger.linux-trace-kernel,org.kernel.vger.netdev |
|---|---|
| Message-ID | <CAO7JXPjnnruhM5oC6xMgnYaQ9efzYFqMCFiJLNM3HCQ+ZeCiJw@mail.gmail.com> |
On Thu, Mar 12, 2026 at 11:49 AM Mathieu Desnoyers <[email protected]> wrote: > > On 2026-03-12 11:40, Steven Rostedt wrote: > > On Thu, 12 Mar 2026 11:28:07 -0400 > > Mathieu Desnoyers <[email protected]> wrote: > > > >>> Note, Vineeth came up with the naming. I would have done "do" but when I > >>> saw "invoke" I thought it sounded better. > >> > >> It works as long as you don't have a tracing subsystem called > >> "invoke", then you get into identifier clash territory. > > > > True. Perhaps we should do the double underscore trick. > > > > Instead of: trace_invoke_foo() > > > > use: trace_invoke__foo() > > > > > > Which will make it more visible to what the trace event is. > > > > Hmm, we probably should have used: trace__foo() for all tracepoints, as > > there's still functions that are called trace_foo() that are not > > tracepoints :-p > > One certain way to eliminate identifier clash would be to go for a > prefix to "trace_", e.g. > > do_trace_foo() > call_trace_foo() This was the initial idea, but it had conflict in the existing source: call_trace_sched_update_nr_running. do_trace_##name also had collisions when I checked. So, went with trace_invoke_##name. Did not check rest of the suggestions here though. Thanks, Vineeth > emit_trace_foo() > __trace_foo() > invoke_trace_foo() > dispatch_trace_foo() > > Thanks, > > Mathieu > > > > -- > Mathieu Desnoyers > EfficiOS Inc. > https://www.efficios.com