> > 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
