On Thu, Aug 20, 2015 at 10:25:23PM +0000, Keller, Jacob E wrote:
> If I understand this correctly, this means that a user passing a
> configuration file missing any option the program reads we will
> terminate the whole program instead of selecting the default?
No, that is not how it works.
The function, config_init(), must be called before calling
config_read(file). [1] In config_init, the items in the 'config_tab'
are loaded into the hash table. The BIST is simply a built in unit
test to confirm that the hash table is working properly.
After that, all *correct* calls to config_get_int/_double cannot
fail. However, if new call sites misspell the option string or mix up
the types, we have to somehow throw an error. Any such error can only
be a programming error, never a user configuration error.
Example: In pi.c, if the developer were to write
s->configured_pi_ki_norm_max =
config_get_int(cfg, NULL, "pi_integral_norm_max");
instead of
s->configured_pi_ki_norm_max =
config_get_double(cfg, NULL, "pi_integral_norm_max");
then the log would show:
ptp4l[1829.910]: config item (null).pi_integral_scale is 0.000000
ptp4l[1829.910]: config item (null).pi_integral_exponent is 0.400000
ptp4l[1829.910]: bug: config option pi_integral_norm_max type mismatch!
In the interest of keeping the config_get_ API clean and simple, I did
not provide a return code to the caller. Instead, we simply bail out
of the program altogether. That is good enough for catching errors
during development.
Thanks,
Richard
1. Once all of the legacy stuff is gone, then config_init() can
allocate the structure and return a pointer to it.
------------------------------------------------------------------------------
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
