Hi, On Wed, Oct 24, 2018 at 02:56:14PM +0000, Wiles, Keith wrote: > > > > On Oct 24, 2018, at 1:18 AM, Olivier Matz <olivier.m...@6wind.com> 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. > > > > Another drawback we need to take in account: it will make the > > backport of patches more difficult, although this is something > > that could be tempered by a script. > > > > While it is obviously better to have a good namespace convention, > > we need to identify the issues we have today before deciding it's > > worth doing the change. > > > > Comments? > > I did not see the deprecation notice in the patches below, but I could have > missed it.
I will send it only if we reach a consensus about the need to apply the patchset. Regards Olivier
