On Mon, Apr 24, 2023 at 05:19:09PM +0200, Walfred Tedeschi wrote: > If they agree it would be great. I think even if we consider a library as > > described below, being able to rely on a header to build on top it would > easier > > the maintenance of the code.
Maybe easier for another project, but I suspect it might make things more difficult for chrony, e.g. if we needed to move something between files with different licenses. I think writing a new header file from scratch and maintaining it shouldn't be too difficult if you really need it. Maybe it could be automated with a script generating the names of the fields and their type. > > Maybe it would be better to start a separate libchrony project from > > scratch, with less restrictive licensing, simple API, an ABI that > > doesn't need to break with future updates, and also support for > > previous versions (chronyc supports only the current version). At > > least the monitoring part, it shouldn't be too much work. I can look > > into it. If it turns out to be working well, we can consider adopting > > it in chrony and rewriting chronyc to use it. > > Here would you be considering to host the code in the same repository? A separate repository, at least for start. If it turns out to be useful and chronyc could easily be ported to it, it would be adopted to the chrony repository. I wrote some minimal code to send a request, process the response and get the fields from the tracking report. It doesn't seem so bad. I'll add the remaining reports and publish it. Commands could be added later if there is interest. -- 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.
