From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Legacy, Allain" <Allain.Legacy@windriver.com>
Subject: Re: [PATCH 1/5] cfgfile: configurable comment character
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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "dev@dpdk.org" <dev@dpdk.org>, "Jolliffe, Ian" <Ian.Jolliffe@windriver.com>
To: "DUMITRESCU, CRISTIAN FLORIN" <cristian.dumitrescu@intel.com>, Yuanhan Liu
 <yuanhan.liu@linux.intel.com>, "RICHARDSON, BRUCE"
 <bruce.richardson@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail5.wrs.com (mail5.windriver.com [192.103.53.11])
 by dpdk.org (Postfix) with ESMTP id 5A959F96F
 for <dev@dpdk.org>; Fri,  3 Mar 2017 12:31:16 +0100 (CET)
In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D8912652758102@IRSMSX108.ger.corp.intel.com>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

> -----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(&params);
	params |=3D flags;
	return _rte_cfgfile_load(filename, &params);
}

struct rte_cfgfile *rte_cfgfile_load_with_params(const char *filename,=20
						    const struct rte_cfgfile_params *params)
{
	return _rte_cfgfile_load(filename, params);
}