[dpdk-dev] symbol conflicts between netinet/in.h, arpa/inet.h, and rte_ip.h
Matthew Hall
mhall at mhcomputing.net
Thu Jul 24 09:59:18 CEST 2014
Hello,
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.
Thus with all the conflicts it's impossible to use a DPDK IP struct instead of
all the system's sockaddr stuff, to store a value from the system copy of
inet_pton. This would be a common operation if, for example, you want to
configure all the IP addresses on your box from a JSON file, which is what I
was doing.
The DPDK kludged around it internally by using a file called
cmdline_parse_ipaddr.c with private copies of these functions. But it in my
opinion very unwisely marked all of the functions as static except for
cmdline_parse_ipaddr, which only works on the DPDK's proprietary argument
handling, and not with anything the user might have which is a different
format.
So, it would be a big help for users if the macros in librte_net files would
check if the symbols already existed, or if they had subheader files available
to grab only non conflicting symbols, or if they would make a proper .h and
factor all the inet_pton and inet_ntop inside the cmdline lib into a place
where users can access them. It would also be a help if they had a less ugly
equivalent to struct sockaddr, which let you work with IP addresses a bit more
easily, such as something like this:
struct ip4_addr {
uint32_t addr;
};
typedef struct ip4_addr ip4_addr;
struct ip6_addr {
uint8_t addr[16];
};
typedef struct ip6_addr ip6_addr;
struct ip_addr {
uint8_t family;
uint8_t prefix;
union {
struct ip4_addr ipv4;
struct ip6_addr ipv6;
};
};
I had to create a bunch of duplicate code to handle it in my project, since
the DPDK marked its copies of all these functions as "secret" and didn't make
a .h for them. If any of it is useful I am happy to donate it, although I
don't think I've got quite enough experience with this specifc part of the
DPDK to code it up all by myself.
Thanks,
Matthew.
More information about the dev
mailing list