RE: [PATCH 0/3] eal: mark API's as stable

["Morten Brørup" <mb@smartsharesystems.com>]

> From: David Marchand [mailto:david.marchand@redhat.com]
> Sent: Thursday, 5 September 2024 09.59
> 
> On Wed, Sep 4, 2024 at 8:10 PM Stephen Hemminger
> <stephen@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.