ntpq meets log files

[James Browning]

On Wed, Mar 10, 2021 at 4:51 AM Hal Murray via devel <devel at ntpsec.org>
wrote:

>
> 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
> smart
> enough to recognize a few special cases.  I'm pretty sure the Intel
> hardware
> directly supports
>   foo += xx
> and hence
>   foo++
> if you use the right instructions.  So we have to use the right macros but
> we
> don't need locks.
>
> There are a few places where it might be nice to update a set of counters
> at
> 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
> system.
>

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
> one
> > 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
> for),
> flags, type tag, pointer to variable, and print routine.  My print routine
> is
> probably your callback.  I'm expecting that we will need a half dozen or
> so
> print routines for the common cases (int, long int, unsigned long...,
> float,
> double...) and a half dozed or so slots that need a dedicated print
> routine.
>

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
more difficult.

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...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20210310/1d6dd970/attachment.htm>