22/10/2018 23:24, Ananyev, Konstantin: > From: Thomas Monjalon > > 22/10/2018 15:37, Andrew Rybchenko: > > > On 10/22/18 4:15 PM, Thomas Monjalon wrote: > > > > The MAC addresses of a port can be matched with devargs. > > > > > > > > As the conflict between rte_ether.h and netinet/ether.h is not resolved, > > > > the MAC parsing is done with a rte_cmdline function. > > > > As a result, cmdline library becomes a dependency of ethdev. > > > > > > > > Signed-off-by: Thomas Monjalon <tho...@monjalon.net> > > > > > > I'd like to share my thought about a new dependency. > > > Looking at cmdline I think that it is a bad and strange > > > dependency for kvargs. IMHO, even duplication of the > > > code to parse MAC address it less evil in this case. > > > > cmdline is not a dependency for kvargs. > > I have added it as a dependency for ethdev. > > > > > May be it is possible to provide internal wrapper > > > which is implemented using ether_aton_r() and located > > > in a separate C file which does not include rte_ether.h etc? > > > > I raised the issue in technical board and it has been decided to fix the > > conflict with libc in the next release (with Olivier's help). > > So Bruce and me decided to use cmdline function in the meantime. > > As I can see, cmdline_parse_etheraddr() uses > static struct ether_addr * > my_ether_aton(const char *a) > internally. > Why not to make it public, rename to rte_ethet_aton(), > and move into rte_net? > And use that one instead? > Later if/when we'll have name conflict with libc resolved, > It can become just a wrapper around ether_aton_r(). > Konstantin
Several reasons: - It would be one more (useless) wrapper - cmdline_parse_etheraddr is already used in several places - ether_aton_r and my_ether_aton may have a different behaviour When the libc conflict will be solved, I prefer replacing uses of cmdline_parse_etheraddr one by one.