On Fri, Mar 03, 2017 at 12:17:47PM +, Legacy, Allain wrote:
> > -Original Message-
> > From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> > Also, for a single parameter like a comment char, I don't think we need to
> go
> > creating a separate structure. The current flags pa
> -Original Message-
> From: Legacy, Allain [mailto:allain.leg...@windriver.com]
> Sent: Friday, March 3, 2017 12:19 PM
> To: Dumitrescu, Cristian ; Yuanhan Liu
> ; Richardson, Bruce
>
> Cc: dev@dpdk.org; Jolliffe, Ian (Wind River)
> Subject: RE: [dpdk-
> -Original Message-
> From: Dumitrescu, Cristian [mailto:cristian.dumitre...@intel.com]
> I disagree here. I think we must control the set of allowed separators to
> avoid confusion.
I don't understand. What will be confusing? The app owns the file format and
is responsible to ensure th
> -Original Message-
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> 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 usi
> -Original Message-
> From: Legacy, Allain [mailto:allain.leg...@windriver.com]
> Sent: Friday, March 3, 2017 12:14 PM
> To: Dumitrescu, Cristian ; Yuanhan Liu
> ; Richardson, Bruce
>
> Cc: dev@dpdk.org; Jolliffe, Ian (Wind River)
> Subject: RE: [dpdk-
> -Original Message-
> From: Dumitrescu, Cristian [mailto:cristian.dumitre...@intel.com]
> 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
> some other parameters that we could consider
On Fri, Mar 03, 2017 at 11:31:11AM +, Legacy, Allain wrote:
> > -Original Message-
> > From: Dumitrescu, Cristian [mailto:cristian.dumitre...@intel.com]
> > Possible options that I see:
> > 1. Add a new parameters argument to the load functions (e.g. struct
> > cfgfile_params *p), whit
> -Original Message-
> From: Legacy, Allain [mailto:allain.leg...@windriver.com]
> Sent: Friday, March 3, 2017 11:31 AM
> To: Dumitrescu, Cristian ; Yuanhan Liu
> ; Richardson, Bruce
>
> Cc: dev@dpdk.org; Jolliffe, Ian (Wind River)
> Subject: RE: [dpdk-
> -Original Message-
> From: Dumitrescu, Cristian [mailto:cristian.dumitre...@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. Drawb
> > We are trying to avoid adding in extra build-time options to DPDK, so
> > can you please rework this patch to make it a run-time option instead.
>
> +1 for making it a run-time option.
>
> --yliu
>
+1
> > Perhaps just add a set_comment_char() API call to the library. If this
> > is a
On Thu, Mar 02, 2017 at 09:10:15PM +, Bruce Richardson wrote:
> On Thu, Mar 02, 2017 at 02:29:27PM -0500, Allain Legacy wrote:
> > The current cfgfile comment character is hardcoded to ';'. This commit
> > introduces a configuration attribute to allow an application to select a
> > different c
> -Original Message-
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> We are trying to avoid adding in extra build-time options to DPDK, so
> can you please rework this patch to make it a run-time option instead.
> Perhaps just add a set_comment_char() API call to the library
On Thu, Mar 02, 2017 at 02:29:27PM -0500, Allain Legacy wrote:
> The current cfgfile comment character is hardcoded to ';'. This commit
> introduces a configuration attribute to allow an application to select a
> different character. This is to ease adoption by applications that have an
> existin
The current cfgfile comment character is hardcoded to ';'. This commit
introduces a configuration attribute to allow an application to select a
different character. This is to ease adoption by applications that have an
existing configuration file which may use a different comment character.
For i
14 matches
Mail list logo
