On Tue, Mar 11, 2025 at 11:18 AM Morten Brørup <m...@smartsharesystems.com> wrote: > > > From: David Marchand [mailto:david.march...@redhat.com] > > Sent: Tuesday, 11 March 2025 10.56 > > > > 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. > > Excellent. I'm all for automating this! > > Feature creep: > > Have you thought about how this (or related automation) can possibly also > benefit the CI, e.g. for ABI breakage testing? > > Or possible benefits to (automated) documentation of versioned functions? > Or possible benefits to remembering all versioned ABIs when writing the > release notes?
Not really, this series is already touching enough code and needs in detail reviews. A simple ack is pointless. I prefer focusing on just making this part right. -- David Marchand
