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.

Reply via email to