| Re: [chrony-dev] Runtime refclock management |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On 2017-10-05 5:05 AM, Miroslav Lichvar wrote:
On Wed, Oct 04, 2017 at 03:10:15PM -0400, Will Miles wrote:
I think I saw a missing Free() for the driver name and parameter when
adding refclock failed.
Aha! Actually the parameter string and inst struct itself also need to
be Free()d there. Thanks!
From here it seemed to be a lot more straightforward to try and use the
existing client message handling framework rather than have to solve
parallelism issues via the filesystem, write an additional config file
management daemon, and/or fix up any tracking state continuity issues.
Makes perfect sense.
I guess a completely different approach would be to allow multiplexing
with the SOCK driver. Multiple clients could connect to the socket and
each one would have a separate refclock. This could be tricky.
If I'm understanding you correctly, are you thinking of something based
on SOCK_SEQPACKET, where chrony could accept() to get a new fd for each
client, listen for an initial "refclock metadata" packet, then just
readmsg() for the measurement stream? With a couple of the smaller
fixes to start the refclock timers on demand, I don't think it wouldn't
be too hard to build as a quasi-independent subsystem bolted on to the
main poll layer, but it would definitely be a little outside the current
architecture as I understand it. Even then, I'm not sure if it's really
that much different than allowing general "add refclock" commands -
there'd still be a master socket responsible for adding refclocks, just
a different protocol than other remote client commands. At least the
permission management would be easy to document and understand, as the
socket could be created before dropping root.
On the other hand, if there's a long term plan to isolate refclock
hardware IO to seperate daemon(s) for permissions management, security,
etc. (IIRC I recall some discussion of that approach on the ntpsec
mailing list), then building in a standard interface as the one way for
all refclocks to register and report time samples would definitely be
worthwhile.
Unfortunately for me, QNX doesn't support SOCK_SEQPACKET, and
replicating that sort of per-client connection semantics using only
SOCK_STREAM and SOCK_DGRAM would be a pain for sure. :(
In that vein, I also have a patch stream that adds TAI offset tracking for
sources, and implements
https://tools.ietf.org/html/draft-stenn-ntp-extended-information-00 to
communicate TAI offset information between nodes. I definitely wouldn't
recommend it for use on the public internet, but the foundational patches to
transmit and receive NTPv4 extensions might be useful at some future date.
Would it be of any use to post them up here for posterity, even though
there's not really much point in merging anything like it now?
I'd like to see the patches. We will need to work with extension
fields when NTS is implemented. There is still an ongoing debate in
the NTP working group about parsing of extension fields, their types,
etc.
OK, I'll send it shortly!
-Will
--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.