If the bare metal mode is getting yanked, then I think we can go with Antti's advice and just yank the conflicting symbols and use the system versions. -- Sent from my mobile device.
On July 25, 2014 7:40:02 AM PDT, Antti Kantee <pooka at fixup.fi> wrote: >On 25/07/14 10:43, Thomas Monjalon wrote: >>> On 24/07/14 07:59, Matthew Hall wrote: >>>> I ran into some weird symbol conflicts between system netinet/in.h >and DPDK >>>> rte_ip.h. They have a lot of duplicated definitions for stuff like >IPPROTO_IP >>>> and so on. This breaks when you want to use inet_pton from >arpa/inet.h, >>>> because it includes netinet/in.h to define struct in_addr. >> [...] >>> Again, I recommend steering away from any tightrope approaches that >>> "know" which types are non-conflicting, or pick out half-and-half >from >>> the host and IP stack. "Do, or do not, there is no half-and-half" >> >> The general problem here is that DPDK is conflicting with libc. >> So the obvious question would be: "why DPDK needs to redefine libc >stuff"? >> I don't see any obvious answer since bare metal is planned to be >removed. >> (see http://dpdk.org/ml/archives/dev/2014-June/003868.html) > >One reason is if you want DPDK to be a portable network programming >environment. Especially in that case you do not want definitions based > >on hackish assumptions of some particular version of some particular >host implementation. However, I'm not trying to argue if DPDK should >or >shouldn't be that, just that you should either dramatically improve the > >current implementation or nuke it.
