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

[Wiles, Keith]

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