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