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

[Bruce Richardson <bruce.richardson@intel.com>]

On Wed, Mar 26, 2025 at 01:02:32PM +0100, David Marchand wrote:
> 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).
> 

+1 for not exporting it.
-1 for moving to buildtools. I don't see the need to introduce yet another
header path in DPDK. Let's just keep it where it is, or moved slightly in
the EAL folder, and then not export 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/.
> 

Again, don't particularly like buildtools as a path, as it's not really a
tool, just a header file. I'd rather keep the tools folders for scripts and
the like.

/Bruce