From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id E7D587CBC for ; Wed, 17 Oct 2018 15:55:40 +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 fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Oct 2018 06:55:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,392,1534834800"; d="scan'208";a="96016625" 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 06:55:37 -0700 To: =?UTF-8?Q?Ga=c3=abtan_Rivet?= , Thomas Monjalon 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> <20181016155802.2067-1-kevin.laatz@intel.com> <20181016155802.2067-2-kevin.laatz@intel.com> <25255353.InYxgXp6IK@xps> <20181017114550.kugn4tzo6h2svur3@bidouze.vm.6wind.com> From: "Laatz, Kevin" Message-ID: <1319a3a0-0ae3-6336-8284-de1880680995@intel.com> Date: Wed, 17 Oct 2018 14:55:36 +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: <20181017114550.kugn4tzo6h2svur3@bidouze.vm.6wind.com> 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 13:55:41 -0000 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?   Thanks, Kevin