On Mon, Mar 17, 2025 at 4:43 PM David Marchand <david.march...@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
