On Tue, 2026-09-22 at 07:35 -0700, Adrián Moreno wrote: > > > > IIUC, this change only affects the printing and doesn't affect debugging > > tools like retis that attempt to surface the drop reasons. But, maybe > > Adrian and Antoine (CCed) may want to have a glance as well. > > > > I don't think this will affect retis in a bad way. We collect the list > of drop reasons by inspecting the BTF enums. It generally works but we > need to keep track of new subsystems enums being added
Right, that wouldn't really change. > so a dynamically-generated full-list of drop reasons is interesting. > IIUC, the only way for userspace to read this list is by looking at the > event format and parse the printf line, right? Any ideas to make this > more machine-friendly? It's intended to be machine friendly "enough", trace-cmd/perf (via libtraceevent or so I think?) parse and use this? But it's also only available when tracing is enabled. I think if you really wanted to have a full list dynamically exposed at runtime across all kernels, then perhaps dropmonitor or some other netlink interface could expose it? Or maybe another debugfs/sysfs file? I don't know what you need it for, but I think it's out of scope for this patchset, and could even be done without it? johannes
