ntpq meets log files

[Hal Murray]

>>> 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 still don't understand what you mean by deglobalize.

There are some variables that are global.  Sometimes they are in structs but 
the struct is global.

If we have a routine to print long ints, then we can put a pointer to a global 
long int in a table and the code that scans the table can load through that 
pointer and call the appropriate print routine.

There are other cases where a print routine only gets used once, perhaps 
because it has to do some arithmetic or a kernel call.  We will be moving code 
from a select branch to a procedure.

The old select style code was slightly more flexible because the text used to 
get the variable to be printed could convert ints to long ints and process 
expressions (convert from seconds to ms) rather than being restricted to a 
simple pointer.  I think a few extra flags and cases in the print select will 
be worth the sanity when we want to make a change.

---------

[context is text ntpq uses to print for a slot]
>> 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.

ntsinfo prints things like:
NTS client sends:            13647
NTS client recvs good:       12375

The print slot in ntpq is:
        CASE_UINT(CS_nts_client_send, nts_client_send);
The lookup slot says:
#define CS_nts_client_send              120
        { CS_nts_client_send,           RO, "nts_client_send" },

ntpq is asking for "nts_client_send" but printing "NTS client sends"
The print string lives in ntpq and is another place that needs to get updated 
when we add a variable to get printed.

We could add a print string to each slot in the table in ntpq and add another 
command to the ntpq protocol to read the print string and/or read both the 
data and the print string.

Or we could make a convention the print names are derived from the query names 
by changing underscores to spaces and then fixup all the query names to be 
nice print strings.  The fixup step would break things, but I'd be willing to 
do it once.

-------

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

Actually, I'll bet we don't need those print routines.  We can just move the 
body of code to the select arm of the print loop that would call them.


-- 
These are my opinions.  I hate spam.