On Fri, 2026-10-23 at 17:00 +0200, Nam Cao wrote: > Gabriele Monaco <[email protected]> writes: > > That could work, though we'd lose some ergonomics around filtering events, > > not > > so much in the unified tracepoint thing but in what fields events have. We > > would > > need to parse a string (so I wonder if globs can express constraints like > > matching whole words or we'd need to arrange the format to accommodate glob > > limitations). > > Yes. But the transition event thingy (not sure what we are naming that) > is only for debugging RV, and the error event should not appear > often. So I think some parsing overhead is not much of an issue.
It isn't quite the performance overhead, it's that instead of doing --filter 'current == "foo" && event == "bar"' I'm going to need to do something like --filter 'current ~ "* foo x*" && event ~ "*x bar ->*"' So you need to remember the format. You wouldn't need to do that if you know you don't have overlapping names though. It isn't a big issue most of the time, but less ergonomic for us. As John said, debugging models is still a use case. LTL puts some gibberish in these events but they are useful for DA. But probably the simplified code all around is worth this mild complication. Anyway I'd rather try this first for BPF and then introduce it for in-kernel ones. Deprecating per-monitor tracepoints is yet another large change I'd rather keep in a separate series. Thanks, Gabriele
