ntpq meets log files

[Hal Murray]

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

--------


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

------------


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

-- 
These are my opinions.  I hate spam.