[dpdk-dev] rte_eal_init() alternative?

[Thomas F Herbert]

On 10/9/15 11:40 AM, Panu Matilainen wrote:
> On 10/09/2015 01:03 PM, Montorsi, Francesco wrote:
>> Hi Panu,
>>
>>
>>
>>> -----Original Message-----
>>> From: Panu Matilainen [mailto:pmatilai at redhat.com]
>>> Sent: venerdì 9 ottobre 2015 10:26
>>> To: Montorsi, Francesco <fmontorsi at empirix.com>; Thomas Monjalon
>>> <thomas.monjalon at 6wind.com>
>>> Cc: dev at dpdk.org
>>> Subject: Re: [dpdk-dev] rte_eal_init() alternative?
>>>
>>>> Something like the attached patch.
>>>
>>> It seems the patch missed the boat :)
>>
>> Correct, sorry. I'm attaching it now.
>>
>>
>>>
>>>> Note that the attached patch exposes also a way to skip the argv/argc
>>>> configuration process by directly providing a populated configuration
>>>> structure...
>>>> Let me know what you think about it (the patch is just a draft and
>>>> needs more work).
>>>
>>> Can't comment on what I've not seen, but based on comments seen on this
>>> list, having an alternative way to initialize with structures would 
>>> be welcomed
>>> by many. The downside is that those structures will need to be 
>>> exposed in
>>> the API forever which means any changes there are subject to the ABI
>>> process.
>>>
>> Perhaps the init function taking a structure could be an exception
>> for ABI changes... i.e., the format of the configuration is not
>> garantueed to stay the same between different versions, and
>> applications using a shared build of DPDK libraries must avoid using
>> the configuration structure... would that be a possible solution?
>
> Sorry but no, down the path of exceptions lies madness. It'd also be 
> giving the middle finger to people using DPDK as a shared library.
>
> Exported structs are always a PITA and even more so in something like 
> configuration which is expected to keep expanding and/or otherwise 
> changing.
>
> I'd much rather see an rte_eal_init() which takes struct *rte_cfgfile 
> as the configuration argument. That, plus maybe enhance librte_cfgfile 
> to allow constructing one entirely in memory + setting values in 
> addition to getting.
>
>     - Panu -
It is very difficult for application writers to write their own command 
parsers with implementation for -h option. How about a function that 
would verify the init parameters and return with a benign error if the 
options are not correct.
>
>
>
>
>> Thanks,
>> Francesco
>>
>>
>>
>

-- 
Thomas F Herbert Red Hat