On Thu, Feb 5, 2026 at 11:56 PM Alexei Starovoitov <[email protected]> wrote: > > On Thu, Feb 5, 2026 at 1:21 AM Donglin Peng <[email protected]> wrote: > > > > On Wed, Feb 4, 2026 at 10:52 PM Donglin Peng <[email protected]> wrote: > > > > > > On Wed, Feb 4, 2026 at 12:00 AM Alexei Starovoitov > > > <[email protected]> wrote: > > > > > > > > On Tue, Feb 3, 2026 at 7:16 AM Steven Rostedt <[email protected]> > > > > wrote: > > > > > > > > > > On Tue, 3 Feb 2026 21:50:47 +0800 > > > > > Donglin Peng <[email protected]> wrote: > > > > > > > > > > > Testing revealed that sorting within resolve_btfids introduces > > > > > > issues with > > > > > > btf__dedup. Therefore, I plan to move the sorting logic directly > > > > > > into > > > > > > btf__add_enum_value and btf__add_enum64_value in libbpf, which are > > > > > > invoked by pahole. However, it means that we need a newer pahole > > > > > > version. > > > > > > > > > > Sorting isn't a requirement just something I wanted to bring up. If > > > > > it's > > > > > too complex and doesn't achieve much benefit then let's not do it. > > > > > > > > > > My worry is because "cat trace" takes quite a long time just reading > > > > > the > > > > > BTF arguments. I'm worried it will just get worse with enums as well. > > > > > > > > > > I have trace-cmd reading BTF now (just haven't officially released > > > > > it) and > > > > > doing an extract and reading the trace.dat file is much faster than > > > > > reading > > > > > the trace file with arguments. I'll need to implement the enum logic > > > > > too in > > > > > libtraceevent. > > > > > > > > If you mean to do pretty printing of the trace in user space then +1 > > > > from me. > > > > > > > > I don't like sorting enums either in resolve_btfid, pahole or kernel. > > > > Sorted BTF by name was ok, since it doesn't change original semantics. > > > > While sorting enums by value gets us to the grey zone where > > > > the sequence of enum names in vmlinux.h becomes different than in dwarf. > > > > > > Thanks, I agreed. > > > > > > > > > > > Also id->name mapping in general is not precise. > > > > There is no requirement for enums to be unique. > > > > Just grabbing the first one: > > > > ATA_PIO0 = 1, > > > > ATA_PIO1 = 3, > > > > ATA_PIO2 = 7, > > > > ATA_UDMA0 = 1, > > > > ATA_UDMA1 = 3, > > > > ATA_UDMA2 = 7, > > > > ATA_ID_CYLS = 1, > > > > ATA_ID_HEADS = 3, > > > > SCR_ERROR = 1, > > > > SCR_CONTROL = 2, > > > > SCR_ACTIVE = 3, > > > > > > > > All these names are part of the same enum type. > > > > Which one to print? First one? > > > > Another option is to print all matching entries, incurring increased > > overhead and extended trace log length. However, I prefer printing > > the first matching entry, though it might be inaccurate in rare cases. > > I disagree. It's not rare. > I wouldn't print anything. Let user space deal with it.
Okay, I will implement this in libtraceevent first. By the way, would the first patch [1] introducing the for_each_enumand for_each_enum64 helper macros be acceptable? [1] https://lore.kernel.org/lkml/[email protected]/
