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
