On Tue, 22 Sep 2026 13:08:39 +0200 Johannes Berg <[email protected]> wrote:
> Hi, > > Resend with the selftests and the two sashiko findings. Hi Johannes, Could you also add code in the samples/trace_events directory. Perhaps add a new event? This will make it easier to understand exactly how to add new __print_sym()s. FYI, this series did pass all my tests. Thanks, -- Steve > > v2 was: > - rebased on 6.9-rc1 > - always search for __print_sym() and get rid of the DYNPRINT flag > and associated code; I think ideally we'll just remove the older > __print_symbolic() entirely > - use ':' as the separator instead of "//" since that makes searching > for it much easier and it's still not a valid char in an identifier > - fix RCU > > v3: > - fix #undef issues > - fix drop_monitor default > - rebase on linux-trace/for-next (there were no conflicts) > - move net patches to 3/4 > - clarify symbol name matching logic (and remove ")" from it) > > v4: > - fix non-module build and possibly dynamic event handling > > v5: > (https://lore.kernel.org/all/[email protected]/) > - fix build warning in non-module build > > v6: > (https://lore.kernel.org/linux-trace-kernel/[email protected]/) > - rebase > - fix nit from Paolo (I hope, I don't remember changing it > but it looks fixed!) > - fix crash due to wrong data placement > > v7: (this version) > - update ovs selftest > - don't ifdef drop_reason_lookup() prototype > - fix section alignment > > > To recap, it's annoying to have > > irq/65-iwlwifi:-401 [000] 22.790000: kfree_skb: ... reason: 0x20000 > > and much nicer to see > > irq/65-iwlwifi:-401 [000] 22.790000: kfree_skb: ... reason: > RX_DROP_MONITOR > > but this doesn't work now because __print_symbolic() can only > deal with a hard-coded list (which is actually really big.) > > So here's __print_sym() which doesn't build the list into the > kernel image, but creates it at runtime. For userspace, it > will look the same as __print_symbolic() (it literally shows > __print_symbolic() to userspace) so no changes are needed, > but the actual list of values exposed to userspace in there > is built dynamically. For SKB drop reasons, this then has all > the reasons known when userspace queries the trace format. > > I guess patches 3/4 should go through net-next, so not sure > how to handle this patch series. Or perhaps, as this will likely > not cause conflicts (in fact I've been rebasing it for years now), > go through tracing anyway with an Ack from netdev? But I can > also just wait for the trace patch(es) to land and resubmit the > net patches after. Assuming this looks good at all :-) > > Thanks, > johannes _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
