Re: [chrony-dev] libchrony feedback: expose constants
On Thu, Aug 24, 2023 at 12:14:20PM -0700, Thangalin wrote:
> For our use case, we end up performing a lot of string comparisons to
> determine the state of the system via libchrony. Also, we must duplicate
> string constants. This is due to message.c containing values that are
> "hidden" from our application. Namely, the sources_state_enums:
>
> https://gitlab.com/chrony/libchrony/-/blob/main/message.c#L67
>
> Ideally, we'd be able to compare the integer values, rather than the
> strings. This would enable us to drop the duplicated string constants and
> no longer perform string comparisons.
Are you concerned about performance? I think you could hash the
strings into integers if you need faster lookups.
The idea for the API was that it wouldn't need to be changed when
existing reports are extended with new fields or new reports are
added, so applications like chronyc would not even need to be
recompiled.
> static const Constant sources_state_enums[] = { {
> CHRONY_SOURCE_SELECTED, "Selected" }, { CHRONY_SOURCE_NONSELECTABLE,
> "Nonselectable" },{ CHRONY_SOURCE_FALSE_TICKER, "Falseticker" }, {
> CHRONY_SOURCE_JITTERY, "Jittery" }, { CHRONY_SOURCE_UNSELECTED,
> "Unselected" }, { CHRONY_SOURCE_SELECTABLE, "Selectable" }, { 0 }};
>
> Or perhaps even eliminating the dependency on strings altogether in the API
> in favour of enumerated values? Offering a lookup for the values would
> still be useful, and even internationalizable.
We can do that if there is a major benefit for the applications, but
I'd prefer simplicity and less code to maintain.
--
Miroslav Lichvar
--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe"
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the
subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
[chrony-dev] libchrony feedback: expose constants
Hi,
For our use case, we end up performing a lot of string comparisons to
determine the state of the system via libchrony. Also, we must duplicate
string constants. This is due to message.c containing values that are
"hidden" from our application. Namely, the sources_state_enums:
https://gitlab.com/chrony/libchrony/-/blob/main/message.c#L67
Ideally, we'd be able to compare the integer values, rather than the
strings. This would enable us to drop the duplicated string constants and
no longer perform string comparisons.
In effect, what do you think about defining constants in a header file,
instead? Something along the lines of:
static const Constant sources_state_enums[] = { {
CHRONY_SOURCE_SELECTED, "Selected" }, { CHRONY_SOURCE_NONSELECTABLE,
"Nonselectable" }, { CHRONY_SOURCE_FALSE_TICKER, "Falseticker" }, {
CHRONY_SOURCE_JITTERY, "Jittery" }, { CHRONY_SOURCE_UNSELECTED,
"Unselected" }, { CHRONY_SOURCE_SELECTABLE, "Selectable" }, { 0 }};
Or perhaps even eliminating the dependency on strings altogether in the API
in favour of enumerated values? Offering a lookup for the values would
still be useful, and even internationalizable.
We do:
get_field_uinteger( ... )
get_constant_name( ... )
Then compare the constant name against our duplicated string values. We
could probably compare the value returned from get_field_uinteger, but we'd
still have to duplicate the constant values, which could lead to runtime
breakages rather than compile-time errors.
The following would be preferred:
#include
chrony_state cs = get_field_state( ... )
if( cs.value == CHRONY_SOURCE_SELECTED ) { ... }
Or possibly hide the query behind an API call, leading to a simpler check:
// prototype for is_field_state and constant values
#include
// query the state, provide the session, returns a Boolean
if( is_field_state( ..., CHRONY_SOURCE_SELECTED ) ) { ... }
Thoughts?
Re: [chrony-dev] libchrony
On Sat, Jun 03, 2023 at 10:48:33AM +1200, Bryan Christianson wrote: > Ho Miroslav > > I presume that chronyc will eventually use this library. > > If/when that happens I would like to see an option to compile the library as > a static library and with the option to build chronyc with static linkage. Yes, I think that would be the default for compatibility with existing package specs/recipes and shared library would be a new option. > > This would avoid all sorts of dependency issues for me in in running > chronyc/chronyd on multiple versions of macOS. > > The interfaces so far look good to me. Ok, thanks. -- Miroslav Lichvar -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
Re: [chrony-dev] libchrony
Ho Miroslav I presume that chronyc will eventually use this library. If/when that happens I would like to see an option to compile the library as a static library and with the option to build chronyc with static linkage. This would avoid all sorts of dependency issues for me in in running chronyc/chronyd on multiple versions of macOS. The interfaces so far look good to me. Thank you for all your work. Bryan > On 1/06/2023, at 2:51 AM, Miroslav Lichvar wrote: > > I started the new project for chronyd monitoring and management > library that was discussed here recently. > > https://gitlab.com/chrony/libchrony > > Basically, it's a low level library for sending and receiving cmdmon > messages with access to individual fields. Currently, it's monitoring > only and only some reports are supported. Other reports and commands > could be added later if there is interest. > > At this point I'm mainly interested in feedback about the API, if it > looks sane and future proof. > > -- > Miroslav Lichvar > > > -- > To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with > "unsubscribe" in the subject. > For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the > subject. > Trouble? Email listmas...@chrony.tuxfamily.org. > Bryan Christianson br...@whatroute.net -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
[chrony-dev] libchrony
I started the new project for chronyd monitoring and management library that was discussed here recently. https://gitlab.com/chrony/libchrony Basically, it's a low level library for sending and receiving cmdmon messages with access to individual fields. Currently, it's monitoring only and only some reports are supported. Other reports and commands could be added later if there is interest. At this point I'm mainly interested in feedback about the API, if it looks sane and future proof. -- Miroslav Lichvar -- To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
