On 1/3/16, 11:12 AM, "dev on behalf of Jan Viktorin" <dev-bounces at dpdk.org on behalf of viktorin at rehivetech.com> wrote:
>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 > Regards, Keith
