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:
- fix build warning in non-module build
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 patch 3/4 should go through net-next, so not sure
how to handle this patch series. Or perhaps, as this will not
cause conflicts, in fact I've been rebasing it for a long time,
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