On Tue, May 26, 2026 at 6:57 PM Steven Rostedt <[email protected]> wrote: > > On Tue, 26 May 2026 11:07:56 +0100 > Mykyta Yatsenko <[email protected]> wrote: > > > Hi Steven, > > > > Gentle ping on this patch from the series. > > > > Since this part touches tracing, I’d appreciate your thoughts on the > > tracing changes whenever you have a chance. > > > > Hi, > > I've been looking at this and was wondering if there are ways to not > extend the trace_event_class structure. It's added for most trace > events (actually each DECLARE_EVENT_CLASS). Although when things like > BTF is enabled, this is a very small amount of extra memory. > > I haven't been ignoring this. I've just been thinking about other > approaches, but haven't come up with anything. Of course, I haven't > been spending that much time on it, as I've been focused on other > things.
Just in theory, what alternative would there be besides having one extra pointer in trace_event_class struct? Some sort of lookup by name or something? E.g., if we know "call" part at runtime for any given tracepoint for .btf_ids = __bpf_trace_btf_ids_##call, we can probably lookup symbol from kallsyms and fetch BTF IDs that way without extending the struct? FWIW, this type info for tracepoints (classic and raw both) are very useful, because right now one needs to do a bunch of work (subject to break due to kernel type/name changes, etc) to find this, and for various generic tracing tooling this type information is actually a necessity to be useful. That's just to say that it would be great to have this in some form of shape, so please help getting this into acceptable form, thanks! > > -- Steve
