Re: [RFC v4 0/8] Symbol versioning and export rework

[David Marchand <david.marchand@redhat.com>]

On Mon, Mar 17, 2025 at 4:43 PM David Marchand
<david.marchand@redhat.com> wrote:
>
> So far, each DPDK library (or driver) exposing symbols in an ABI had to
> maintain a version.map and use some macros for symbol versioning,
> specially crafted with the GNU linker in mind.
>
> This series proposes to rework the whole principle, and instead rely on
> marking the symbol exports in the source code itself, then let it to the
> build framework to produce a version script adapted to the linker in use
> (think GNU linker vs MSVC linker).
>
> This greatly simplifies versioning symbols: a developer does not need to
> know anything about version.map, or that a versioned symbol must be
> renamed with _v26, annotated with __vsym, exported in a header etc...
>
> Checking symbol maps becomes unnecessary since generated by the build
> framework.
>
> Updating to a new ABI is just a matter of bumping the value in
> ABI_VERSION.
>
>
> Comments please.

- I am considering making rte_function_versioning.h a non exported
header (precisely, moving it to buildtools/ and maybe renaming it).

This header contains macros not prefixed with RTE_.
Using it requires some build trick (see use_function_versioning).
And I don't see symbol versioning as a MUST infrastructure that DPDK
needs to provide to datapath applications.

Yet technically, this change would be an API breakage if some
applications indeed relied on it.

Cc: techboard for info.


- On a similar note, this RFC series adds the rte_exports.h header
(defining RTE_EXPORT*_SYMBOL()) in config/, though its job is for
extracting a symbol list during the build.
So a better location is probably buildtools/.


-- 
David Marchand