Odds and ends

[Hal Murray]

[if (0) on debugging msyslog]
> What I do is delete them unless I think they might have continuing value, in
> which case I put them under DPRINTF.

I agree on the "continuing value" part.

For what I'm after, msyslog is more convenient that DPRINTF.  I'm willing to 
do an edit/build/restart cycle to get the printout I need.  For now, I'll try 
my "if (0)" hack.  If anybody thinks that's too ugly we can discuss 
alternatives.

>> extern  int     clocktime       (int, int, int, int, int, time_t, 
uint32_t, uint32_t *, uint32_t *);
> Fair point.  Are you advocating outting the formal names back in?

I don't have any strong opinions in that area.  That's a particularly ugly 
example.  I ran into a few ugly ones when working on the CMAC authentication. 
 It seems like something we could do better.

[*CAST stuff in ntpd code]
> I agree with moving them to ntpclients.  Anything  that reeduces the amount
> of ceuft ubthe ntpd code is good. 

I didn't find any usage in ntpclients so there probably isn't any need to 
move them.  We should concentrate on removing code from ntpd.

If we find things like "if (xxx->flags & MCAST)" but there is no way that the 
flag ever gets set, then we can just remove the code.

[counters that get reset every hour after writing to log file]
> Reasonable. Would you make ntpq parse the logfile?

No, that's ugly and only works if you are on the system with the log files.

I was thinking of having ntpd maintain 2 sets of counters.  The new set is 
parallel to the current set.  It gets updated when the current set is 
cleared.  When ntpq asks, ntpd would return both values.

[ntpq -p showing authenticated slots]
> No need. Just boldface the ones with authentication.

I like it.  What happens if I cut/paste into email?


-- 
These are my opinions.  I hate spam.