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

[Thomas Monjalon <thomas@monjalon.net>]

17/10/2018 16:09, Laatz, Kevin:
> Hi Thomas,
> 
> 
> On 17/10/2018 14:46, Thomas Monjalon wrote:
> > 17/10/2018 13:45, Gaëtan Rivet:
> >> 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 the right word is "run-time option".
> > An option can have a parameter.
> > If this API is not supporting options with parameters, the name is
> > really misleading.
> The option will be passed like any other EAL option. Right now it 
> doesn't support any parameters but in future we could add functionality 
> like we had with the --vdev solution where we can pass selftest=1 with 
> the telemetry option.
> >
> >> 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.
> > "enabled" can be documented as the result of the option parsing.
> > If the option is given to rte_eal_init, it becomes enabled.
> The Doxygen comments mention that the flag should initially be set to 0 
> and will be set to 1 if the option for the relevant callback is passed 
> to EAL when running your application.

Saying "passed to EAL" is too vague.
You need to differentiate the option parsing and the init.
Both are done in EAL, that's why you need to be more specific.

> >> 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?
> > rte_option looks OK.
> I'm happy to change it to rte_option if we have consensus on it :)

OK, thanks

> > The global picture may be better explained I think.
> > Any help with wording and documentation is appreciated, thanks.
> 
> Thanks,
> Kevin
> 
>