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.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). >
+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
