From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail5.wrs.com (mail5.windriver.com [192.103.53.11]) by dpdk.org (Postfix) with ESMTP id 5A959F96F for ; Fri, 3 Mar 2017 12:31:16 +0100 (CET) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail5.wrs.com (8.15.2/8.15.2) with ESMTPS id v23BVE7J030514 (version=TLSv1 cipher=AES128-SHA bits=128 verify=OK); Fri, 3 Mar 2017 03:31:15 -0800 Received: from ALA-MBC.corp.ad.wrs.com ([fe80::fcbe:9b7:1141:89a1]) by ALA-HCA.corp.ad.wrs.com ([147.11.189.40]) with mapi id 14.03.0294.000; Fri, 3 Mar 2017 03:31:13 -0800 From: "Legacy, Allain" To: "DUMITRESCU, CRISTIAN FLORIN" , Yuanhan Liu , "RICHARDSON, BRUCE" CC: "dev@dpdk.org" , "Jolliffe, Ian" Thread-Topic: [dpdk-dev] [PATCH 1/5] cfgfile: configurable comment character Thread-Index: AQHSk5lpFVKuCWJbrUeFRCC27PQYOKGC0BiAgACuOYD//3sQMA== Date: Fri, 3 Mar 2017 11:31:11 +0000 Message-ID: <70A7408C6E1BFB41B192A929744D85238A75B22B@ALA-MBC.corp.ad.wrs.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> In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D8912652758102@IRSMSX108.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.224.140.166] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 1/5] cfgfile: configurable comment character 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: Fri, 03 Mar 2017 11:31:16 -0000 > -----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) fie= ld > 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 t= he existing API as is and a wrapper that accepts additional parameters. S= omething like the following (with implementations in the .c obviously rathe= r 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.) w= here we use a common function invoked by higher level functions that pass i= n additional parameters to customize behavior. struct rte_cfgfile *_rte_cfgfile_load(const char *filename,=20 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 |=3D flags; return _rte_cfgfile_load(filename, ¶ms); } struct rte_cfgfile *rte_cfgfile_load_with_params(const char *filename,=20 const struct rte_cfgfile_params *params) { return _rte_cfgfile_load(filename, params); }