ntpq meets log files
jamesb.fe80 at gmail.com
Wed Mar 10 21:00:00 UTC 2021
On Wed, Mar 10, 2021 at 4:51 AM Hal Murray via devel <devel at ntpsec.org>
> James Browning said:
> >> We need to keep in mind how to make this work in a multi threaded
> >> environment.
> > I think you would need to deglobalize some variables first.
> What do you have in mind?
I tend to overfocus on early optimizations and other trivial
things. Neither of the arguments passed to read_clockstatus
from the converted mockup is used, instead, the variable
res_associd is pulled from being global.
> I think there is an Atomic "library" that is mostly the compiler being
> enough to recognize a few special cases. I'm pretty sure the Intel
> directly supports
> foo += xx
> and hence
> if you use the right instructions. So we have to use the right macros but
> don't need locks.
> There are a few places where it might be nice to update a set of counters
> the same time. For example, the number of packets received and the number
> processed or dropped or ... I'm willing to live with that fuzz on a busy
IIRC, I saw that was mentioned as a C11, feature and not C99.
> >> There is a slight complication. We need the name that comes back with a
> >> variable to be a meaningful description.
> > So, drop the Millsian object notation (or whatever it is called) for
> > something closer to JSON? Protobuf need not apply.
> I'm not interested in JSON.
> We could add a pretty name to the table and a way for ntpq to ask for the
> pretty name.
You lost me put up a mockup, please.
> > For example, after butchering all the following it occurred to me that
> > could just ad a CB (callback) or HOOK value. I mean it is not like there
> is a
> > sudden lack of space for them.
> I wouldn't have called it "callback". There is no back part.
> My straw man is that each slot in the table has a name (that ntpq asks
> flags, type tag, pointer to variable, and print routine. My print routine
> probably your callback. I'm expecting that we will need a half dozen or
> print routines for the common cases (int, long int, unsigned long...,
> double...) and a half dozed or so slots that need a dedicated print
Unless you make the handlers smarter I think there will be
more than 6 corner cases that need extra help. It would
probably be best to separate the low easy corners from the
ctl_putdata and ctl_putunqstr are probably lower-level
implementations than you intend.
ctl_putuint is common, ctl_putint less so. ctl_putts,
ctl_putadr, ctl_putrefid, ctl_putarray, and ctl_putstr are
also already there.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel