Re: [dpdk-dev] Non-argv dependant rte_eal_init() call

[Thomas Monjalon <thomas.monjalon@6wind.com>]

Hello,

01/08/2013 17:37, Marc Sune :
> In our case, we are right now simply faking the argv, which is a little
> bit ugly:
> <code>
> //...
>   37         const char* argv[EAL_ARGS] = {"./fake", "-c",CORE_MASK,
> "-n",NUM_CACHE_LINES, ""};
> //...
>   53         ret = rte_eal_init(EAL_ARGS, (char**)argv);
>   54         if (ret < 0)
>   55                 rte_exit(EXIT_FAILURE, "rte_eal_init failed");
> //...
> </code>

You should provide a better binary name because in your example, your logs 
will be prefixed with "fake" which is, I agree with you, a little bit ugly ;)

> IMHO it would make more sense to have actually two calls, adding a
> library-like initialization. Something like:
> 
> <code>
> /*
> * In the comments a warning that this should be called at the very
> beginning of the program.
> *...
> */
> int rte_eal_init(eal_coremask_t core_mask, unsigned int num_of_lines
> /*More parameters here...*/);
> 
> /*
> *
> */
> int rte_eal_init_argv(int argc, char **argv);
> 
> </code>

The problem with your proposal is that the number of options is static.
So when adding a new option in future releases, all the applications should be 
updated to give a (probably null) value for this new option.
Not sure it is an improvement.

> Btw, the same applies to the mangling of the main() (MAIN) routine. Is
> this really necessary? Isn't it enough to clearly state in the
> documentation that certain API calls need to be made on the very
> beginning of the application?

Not sure to understand this point.
MAIN is only defined in examples for the bare-metal use case.
What is the link with the API ?

-- 
Thomas