> From: David Marchand [mailto:david.march...@redhat.com] > Sent: Thursday, 5 September 2024 09.59 > > On Wed, Sep 4, 2024 at 8:10 PM Stephen Hemminger > <step...@networkplumber.org> wrote: > > > > The API's in ethtool from before 23.11 should be marked stable. > > EAL* ? > > > Should probably include the trace api's but that is more complex change. > > On the trace API itself it should be ok.
No! Trace must remain experimental until controlled by a meson option, e.g. "enable_trace", whereby trace can be completely disabled and omitted from the compiled application/libraries/drivers at build time. <rant> Furthermore, I would prefer having trace as a separate library, not part of the EAL bloat. The EAL should - as its name says - provide hardware and O/S abstractions, not a collection of features. </rant> > The problem is with the tracepoint variables themselves, and I don't > think we should mark them stable. Agree. They are only there - as a middle step - to assist generating the trace output, so I don't see any benefit in marking them stable. We could introduce a means to mark their trace output format as stable; but only if some trace output processors actually benefit from this. And it introduces extra work for maintaining trace points and adding new trace points.
