>>> 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.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
