On Wed, Oct 24, 2018 at 10:18:19AM +0200, Olivier Matz wrote:

This RFC targets 19.02.

The rte_net headers conflict with the libc headers, because
some definitions are duplicated, sometimes with few differences.
This was discussed in [1], and more recently at the techboard.

Before sending the deprecation notice (target for this is 18.11),
here is a draft that can be discussed.

This RFC adds the rte_ (or RTE_) prefix to all structures, functions
and defines in rte_net library. This is a big changeset, that will
break the API of many functions, but not the ABI.

One question I'm asking is how can we manage the transition.
Initially, I hoped it was possible to have a compat layer during
one release (supporting both prefixed and unprefixed names), but
now that the patch is done, it seems the impact is too big, and
impacts too many libraries.

Few examples:
  - rte_eth_macaddr_get/add/remove() use a (struct rte_ether_addr *)
  - many rte_flow structures use the rte_ prefixed net structures
  - the mac field of virtio_net structure is rte_ether_addr
  - the first arg of rte_thash_load_v6_addrs is (struct rte_ipv6_hdr *)
  ...

Therefore, it is clear that doing this would break the compilation
of many external applications.

Can you clarify a bit as to why we can't keep around compatibility versions
of the headers, alongside the new versions? I'm not following the logic
above. Can we not introduce completely new headers with the replacements
while leaving the old ones intact?

/Bruce