[dpdk-dev] [PATCH 1/5] cfgfile: configurable comment character

Dumitrescu, Cristian cristian.dumitrescu at intel.com
Fri Mar 3 12:17:11 CET 2017


> > 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 setting per cfgfile instance it would then allow applications to
> > simultaneously use files with different formats. For example, if in
> > future we use cfgfile library to configure DPDK EAL, a preexisting file
> > for that shipped with DPDK may conflict in format with an
> > application-specific one.
> >

I don't think this approach will work well for the current implementation, as the config file load function simply complete the parsing on the file in a single step, so any update of the comment char after the load function will not produce any effects.

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.
2. Use the flags argument. Basically define a new flag value for each acceptable comment char. It does not require an API change, it has the advantage of limiting the characters that can be accepted as comments (as we probably do not want to allow e.g. letters, digits, tab, space, unprintable chars, etc here). I am OK with adding all the commonly used single character comment separators ("; # % @ !"), with the default as the current option of ";"

My vote will be to go for option 2. Naming convention proposal:
RTE_CFGFILE_COMMENT_SEPARATOR_CHR33; /**< ! */
RTE_CFGFILE_COMMENT_SEPARATOR_CHR35; /**< # */
RTE_CFGFILE_COMMENT_SEPARATOR_CHR37; /**< % */
RTE_CFGFILE_COMMENT_SEPARATOR_CHR59; /**< ; */
RTE_CFGFILE_COMMENT_SEPARATOR_CHR64; /**< @ */
Of course, the flags argument needs to be checked for the presence of a single separator char flag.

Regards,
Cristian



More information about the dev mailing list