From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id CA8125F27 for ; Wed, 17 Oct 2018 16:09:06 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Oct 2018 07:09:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,392,1534834800"; d="scan'208";a="96022155" Received: from klaatz-mobl.ger.corp.intel.com (HELO [10.252.25.138]) ([10.252.25.138]) by fmsmga002.fm.intel.com with ESMTP; 17 Oct 2018 07:09:02 -0700 To: Thomas Monjalon , =?UTF-8?Q?Ga=c3=abtan_Rivet?= Cc: dev@dpdk.org, harry.van.haaren@intel.com, stephen@networkplumber.org, shreyansh.jain@nxp.com, mattias.ronnblom@ericsson.com, bruce.richardson@intel.com References: <20181011165837.81030-1-kevin.laatz@intel.com> <25255353.InYxgXp6IK@xps> <20181017114550.kugn4tzo6h2svur3@bidouze.vm.6wind.com> <5281106.4Q2nRubcPx@xps> From: "Laatz, Kevin" Message-ID: Date: Wed, 17 Oct 2018 15:09:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <5281106.4Q2nRubcPx@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [dpdk-dev] [PATCH v5 01/13] eal: add param register infrastructure X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 14:09:07 -0000 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. > >> 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 :) > > The global picture may be better explained I think. > Any help with wording and documentation is appreciated, thanks. Thanks, Kevin