Open Emanuesson opened 1 year ago
"Add 'RTE_ETH' namespace to all enums & macros in a backward compatible way."
A more correct way to describe this change would be "use a prefix in names", not "add a namespace". But anyway. It might help to understand which particular part of this change is backward-compatible.
I was also surprised by such an extensive API-change in a project like DPDK. However, I'm just "affected" as well and have no real explanation or intention available why this change was necessary or what incompatibilities come along with this change. The DPDK-Changelog may help here.
Add 'RTE_ETH' namespace to all enums & macros in a backward compatible way. The macros for backward compatibility can be removed in next LTS. Also updated some struct names to have 'rte_eth' prefix.
I guess part of the contract between DPDK developers and developers of code that uses DPDK "APIs" is "the DPDK developers reserve the right to make incompatible changes, or to make "compatible" changes and then remove the compatibility in a future release, and the developers will say "thank you, sir, may I have another?" and change their code every time we decide to change out "APIs"."
This is not a contract that I would sign if I had a choice about it; I guess the DPDK developers don't want developers unwilling to put up with that. (The DPDK code in libpcap was dropped in from a helicopter; we're now kinda stuck with it. At this point, I view it as a strong argument for providing a plugin mechanism in libpcap - albeit one that limits the locations from which plugins can be loaded, for security reasons, given that, unfortunately, a number of capture mechanisms requite root privilege - and leave it up to Somebody Else, possibly the DPDK developers themselves, to keep it working.)
(The libpcap contract, at least to the extent that I can enforce it, includes "the only way in which we will break the API or the ABI intentionally are maybe to drop older interfaces that have been marked as deprecated for a long time"; so far, I don't think we've dropped any older interfaces yet.)
solutions?
solutions?
Somebody with DPDK experience (hint: not me) and who has an interest in DPDK support (hint: not me) modifies it or rewrites it? At this point, I'm sorry we picked this code up; it would perhaps have been better had the DPDK developers maintained their own version of libpcap with DPDK support.
Due to changes in the shipped headers by DPDK, especially within the following commit, libpcap became incompatible to compile against dpdk: https://github.com/DPDK/dpdk/commit/295968d1740760337e16b0d7914875c5cac52850
How to reproduce:
Reproduced with the following versions:
The following compiler-errors are visible during the build: