From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <cristian.dumitrescu@intel.com>
Received: from mga04.intel.com (mga04.intel.com [192.55.52.120])
by dpdk.org (Postfix) with ESMTP id 65002952
for <dev@dpdk.org>; Fri, 3 Mar 2017 13:07:30 +0100 (CET)
Received: from orsmga002.jf.intel.com ([10.7.209.21])
by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
03 Mar 2017 04:07:29 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.35,236,1484035200"; d="scan'208";a="55459547"
Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3])
by orsmga002.jf.intel.com with ESMTP; 03 Mar 2017 04:07:28 -0800
Received: from irsmsx112.ger.corp.intel.com (10.108.20.5) by
IRSMSX108.ger.corp.intel.com (163.33.3.3) with Microsoft SMTP Server (TLS) id
14.3.248.2; Fri, 3 Mar 2017 12:07:26 +0000
Received: from irsmsx108.ger.corp.intel.com ([169.254.11.173]) by
irsmsx112.ger.corp.intel.com ([169.254.1.175]) with mapi id 14.03.0248.002;
Fri, 3 Mar 2017 12:07:26 +0000
From: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
To: "Legacy, Allain (Wind River)" <allain.legacy@windriver.com>, Yuanhan Liu
<yuanhan.liu@linux.intel.com>, "Richardson, Bruce"
<bruce.richardson@intel.com>
CC: "dev@dpdk.org" <dev@dpdk.org>, "Jolliffe, Ian (Wind River)"
<ian.jolliffe@windriver.com>
Thread-Topic: [dpdk-dev] [PATCH 1/5] cfgfile: configurable comment character
Thread-Index: AQHSk4tgAm80mLhvyUurDX68XH1fJKGCC6+AgAA+aICAAKeiQIAACoGAgAAHsWA=
Date: Fri, 3 Mar 2017 12:07:25 +0000
Message-ID: <3EB4FA525960D640B5BDFFD6A3D8912652758220@IRSMSX108.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>
In-Reply-To: <70A7408C6E1BFB41B192A929744D85238A75B22B@ALA-MBC.corp.ad.wrs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMjdmMzA4YTItYWYyOS00NThlLWE5ODMtNjk5ODYzOGM2NDZjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjIuMTEuMCIsIlRydXN0ZWRMYWJlbEhhc2giOiJrNm9JQWpyNmxFc1RaRjdQUHVaR3FqVE1neFFaZXN2ZWNUeFwvcXd3MzFsMD0ifQ==
x-ctpclassification: CTP_IC
x-originating-ip: [163.33.239.180]
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 <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>
X-List-Received-Date: Fri, 03 Mar 2017 12:07:30 -0000
> -----Original Message-----
> From: Legacy, Allain [mailto:Allain.Legacy@windriver.com]
> Sent: Friday, March 3, 2017 11:31 AM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Yuanhan Liu
> <yuanhan.liu@linux.intel.com>; Richardson, Bruce
> <bruce.richardson@intel.com>
> Cc: dev@dpdk.org; Jolliffe, Ian (Wind River) <ian.jolliffe@windriver.com>
> Subject: RE: [dpdk-dev] [PATCH 1/5] cfgfile: configurable comment charact=
er
>=20
> > -----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) f=
ield
> > of this struct. Drawbacks: API change that might have to be announced o=
ne
> > release before the actual API change.
>=20
> 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 ra=
ther
> 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 w=
e
> use a common function invoked by higher level functions that pass in
> additional parameters to customize behavior.
>=20
> struct rte_cfgfile *_rte_cfgfile_load(const char *filename,
> const struct rte_cfgfile_params
> *params);
>=20
> struct rte_cfgfile *rte_cfgfile_load(const char *filename, int flags)
> {
> struct rte_cfgfile_params params;
>=20
> rte_cfgfile_set_default_params(¶ms);
> params |=3D flags;
> return _rte_cfgfile_load(filename, ¶ms);
> }
>=20
> struct rte_cfgfile *rte_cfgfile_load_with_params(const char *filename,
> const struct
> rte_cfgfile_params *params)
> {
> return _rte_cfgfile_load(filename, params);
> }
Regardless of the approaches 1. or 2., we must control the acceptable set o=
f chars for the comment separator, and the way to do this is through enum/f=
lags.
Both approaches can support this. Therefore, IMO the separator char is not =
enough to justify approach 1. I would only go for approach 1 if there are s=
ome other parameters that we could consider adding to the load function now=
or later. Do you see any?