From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Richardson Subject: Re: [PATCH 1/5] cfgfile: configurable comment character Date: Fri, 3 Mar 2017 12:10:20 +0000 Message-ID: <20170303121020.GA193932@bricha3-MOBL3.ger.corp.intel.com> References: <1488482971-170522-1-git-send-email-allain.legacy@windriver.com> <1488482971-170522-2-git-send-email-allain.legacy@windriver.com> <20170302211015.GA18940@bricha3-MOBL3.ger.corp.intel.com> <20170303005337.GB18844@yliu-dev.sh.intel.com> <3EB4FA525960D640B5BDFFD6A3D8912652758102@IRSMSX108.ger.corp.intel.com> <70A7408C6E1BFB41B192A929744D85238A75B22B@ALA-MBC.corp.ad.wrs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Dumitrescu, Cristian" , Yuanhan Liu , "dev@dpdk.org" , "Jolliffe, Ian (Wind River)" To: "Legacy, Allain" Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 088D836E for ; Fri, 3 Mar 2017 13:10:24 +0100 (CET) Content-Disposition: inline In-Reply-To: <70A7408C6E1BFB41B192A929744D85238A75B22B@ALA-MBC.corp.ad.wrs.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Mar 03, 2017 at 11:31:11AM +0000, Legacy, Allain wrote: > > -----Original Message----- > > From: Dumitrescu, Cristian [mailto:cristian.dumitrescu@intel.com] > > Possible options that I see: > > 1. Add a new parameters argument to the load functions (e.g. struct > > cfgfile_params *p), whit the comment char as one (and currently only) field > > of this struct. Drawbacks: API change that might have to be announced one > > release before the actual API change. > > I would prefer this option as it provides more flexibility. We can leave the existing API as is and a wrapper that accepts additional parameters. Something like the following (with implementations in the .c obviously rather than inline the header like I have it here). There are several examples of this pattern already in the dpdk (i.e., ring APIs, mempool APIs, etc.) where we use a common function invoked by higher level functions that pass in additional parameters to customize behavior. > > struct rte_cfgfile *_rte_cfgfile_load(const char *filename, > const struct rte_cfgfile_params *params); > > struct rte_cfgfile *rte_cfgfile_load(const char *filename, int flags) > { > struct rte_cfgfile_params params; > > rte_cfgfile_set_default_params(¶ms); > params |= flags; > return _rte_cfgfile_load(filename, ¶ms); > } > > struct rte_cfgfile *rte_cfgfile_load_with_params(const char *filename, > const struct rte_cfgfile_params *params) > { > return _rte_cfgfile_load(filename, params); > } No need for a new API. Just add the extra parameter to the existing load parameter and use function versioning for ABI compatilibity. Since it's only one function, I don't think using versioning is a big deal, and that's what it is there for. Also, for a single parameter like a comment char, I don't think we need to go creating a separate structure. The current flags parameter is unused, so just replace it with the comment char one. With using the structure, any additions to the struct would be an ABI change anyway, so I see little point in using it, unless we already know of additional parameters we will be adding in future. [It's an ABI change even when adding to the end, since the struct is allocated in the app itself, not the library.] /Bruce