[dpdk-dev] [RFC 1/7] eal/common: define rte_soc_* related common interface

[Jan Viktorin]

On Sat, 2 Jan 2016 19:45:40 +0100
Jan Viktorin <viktorin at rehivetech.com> wrote:

> > 
> > Do you consider this will break binary compatibility since
> > sizeof (rte_soc_addr) is PATH_MAX (1024) and the other elements of the
> > union inside rte_devargs are much smaller (like 32 bytes).
> >   
> 
> I had a bad feeling about this... Originally, I started with a pointer
> 'const char *' so it can be done that way... However, this brings
> compilator mad as it does not allow to cast char * -> const char *
> because of the strict DPDK compilation settings. I didn't find any
> workaround yet. I think I can make it just 'char *' for the next version
> of the patch set.

Having rte_devargs to contain only char * instead of char[PATH_MAX]
brings an issue. There is no common devargs_free function. Inside the
function rte_eal_devargs_add, I must malloc memory here to fill the
devtree_path. But there is no general way to free it. At least, I
didn't find such code... I need to do this:

108         case RTE_DEVTYPE_WHITELISTED_SOC:
109         case RTE_DEVTYPE_BLACKLISTED_SOC:
110                 devargs->soc.addr.devtree_path = strdup(buf);

because the buf variable is deallocated at the end of the function.

In fact, I do not clearly understand the rte_eal_devargs_add function.
What is the expected input? The call to rte_eal_parse_devargs_str
separates the string into drvname and drvargs. What are the drvargs
supposted to be? I'd expect the user types -w <deviceid> or -b <deviceid>
(for PCI <deviceid> is the quaternion, for SoC it's the device-tree
path).

Regards
Jan

-- 
  Jan Viktorin                E-mail: Viktorin at RehiveTech.com
  System Architect            Web:    www.RehiveTech.com
  RehiveTech
  Brno, Czech Republic