[dpdk-dev] [PATCH v5 01/13] eal: add param register infrastructure

[Laatz, Kevin]

Hi Thomas,

On 17/10/2018 12:45, Gaëtan Rivet wrote:
> Hi Thomas,
>
> On Wed, Oct 17, 2018 at 11:41:53AM +0200, Thomas Monjalon wrote:
>> I still think all the wording is incorrect.
>> Please start by describing what is "param", "flag" and "option" in your mind.
>> They are all mentioned in this file.
>> Are you sure rte_param is the right name?
> I suggested the name rte_param, I think the original proposal was
> rte_lib_init, which to me unduly diminished the intent of these structures.
>
> I think rte_param seems proper, this is a generic parameter object
> description. The integer "enabled" is described as a flag in the
> structure, as it is used to flag the init routine down the road to
> trigger the init callback associated with this parameter.
The purpose of "enabled" is to avoid redundantly calling all of the 
callbacks in rte_param_list. Enabled should always be initialized to 0 
by the library (as described in the Doxygen comment) and it will be set 
if the 'option' for the callback is passed to EAL when running the 
application (this is done in rte_param_parse).
To avoid confusion, I have renamed eal_flag to eal_option in the param 
struct and reworded the Doxygen comments accordingly. The only place 
flag is mentioned now is for "enabled".
>
> eal_option is reminiscent of optarg / optind of getopt() family,
> which seems fitting.
>
> I don't mean to overstep Kevin's role defending his work, but given
> that I proposed some of this naming and pushed for this direction to be
> taken in the first place, I feel I should help explain my propositions.
>
> rte_param could become rte_parameter or rte_option instead, eal_option
> could become opt_string or opt_str, and so on, do you have specific
> ideas about proper names?
I think rte_param was an improvement on rte_lib_init, for reasons 
mentioned by Gaetan.
I am open to renaming it if you have any better, more descriptive name 
in mind?

  <snip>

Thanks,
Kevin