If this happens the imsg may no longer be usable as there may be queued
messages, but this is a) already the case with the code now, and b)
would be the case if recvmsg() fails anyway, so we can document that -1
from imsg_read() invalidates the struct imsgbuf.
discussed with and ok eric
function, which is additionally exported for use by others.
It will be needed by smtpd's SSL module when the SMTP client code
is changed to replace libevent's evbuffers with our msgbuf_* API.
ok gilles@ henning@ guenther@ eric@
Currently the receiver fetches an imsg via imsg_get() and if he expects
an fd, he then calls imsg_get_fd() to fetch the next fd queued on the
imsgbuf from which the imsg came.
This changes hides the fd queueing mechanism to the API user. When closing
an imsg with an fd, the message is flagged so that the receiving end knows
it must dequeue the fd in imsg_get() and return it with the imsg structure.
This way there is no (less) possible screw up from imsg_get_fd() not being
called directly after imsg_get() by the user. The retreived imsg is
self-contained.
ok pyr@, "I like that" henning@
corrections more often. Due to physical effects crystal oscillators aren't
really stable beyond 1000s or so - at least not the kind found in pc's.
ok henning
offset. This avoids future frequency adjustments based on measurements of a
clock that was being adjusted. End result: more stable clock and better
frequency convergence.
Also, fix a mis-ordered structure member while I'm here.
ok henning
reply instead of doing it in ntpd itself by getting the time we read
from the socket. based on a diff from mickey hacked in shape by me,
lots of testing and review from ckuethe and sthen, theo and claudio like it
too
the first query we will never do the settime because
SENSOR_QUERY_INTERVAL (30s) is greater than SETTIME_TIMEOUT (15s). so
during the settime period only, be more aggressive and use
SETTIME_TIMEOUT/3 for the query interval.
ok henning@
which only works in w.europe
- use a more realistic value for udcf correction example
- use a GPS-only receiver for "refid GPS" example
suggested/ok mbalmer
the offset since we use monotime for these for some time now, and monotime
is not affected by system time changes (like, duh, that was the reason for
the change). PR5927
reason: the parent process must never ever block, but the dns routines can.
last not least this fixes ntpd -s 'hanging' for a long time.
tested by a couple of people
nicm