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