Hal Murray <hmur...@megapathdsl.net>: > > I'll study authinfo and get back to you, probably tomorrow. > > authinfo is a bad example. ntpq has its own copy of that list.
ntpq has its own copy of the lists for almost *all* the standard ntpq displays. There are only three exceptions; those lists are in ntp_control.c > I thought there was at least one command that didn't need it's own list, but > I > can't find an example. Three. The default system variables, the default peer variables, and the default clock variables. That's as opposed to nine display groups defined in ntpq.py. > Beware, you may get sucked in. The swamp is pretty deep, but it's the sort > of > problem you are good at. The fundamental problem is that there are 3 tables > that have to be kept in sync. > There is a text "table" of #defines to assign sequential numbers to handles, > a table of strings for mapping strings to handles, > and a final select on handle to format the result. > > You will see when you get there if you don't remember. I'm slightly > surprised > you haven't cleaned it up already. Never seemed urgent before. Now, I want to get the code to where adding your NTS counters has a lot less friction and ad-hockery about it. I figure this is my next day or so of work. You have identified one issue - the tables in ntp-Control.c are a mess. Here's what I said about that in a comment on issue #539: I can easily reduce the number of tables from 6 to 3. The cost of the only non-complicated way to do it is that the order in which variables in the default displayed set are printed would change - the second table in each pair exists to define the order of that traversal. I don't think this is a real problem. But you're the one with ops experience, not me. If you confirm that it isn't, I'll make the change. Now I can add this: at least one of the orderings wired into ntp_control.c is there to preserve exact interface compatibility with the extinct species "fuzzball"! In 2019 this seems silly. The other is the fact that policy (the assignment of which variables are in which display groups) is split between two places, ntp_control.c and ntpq. This is wrong and unstable and I *will* fix it now that I've actually noticed it. ntpq.py has comments in it that read # FIXME: This table should move to ntpd # so the answers track when ntpd is updated I think that - moving policy into ntp_control.c - is the wrong direction. Mechanism belongs in ntp_control.c; policy should migrate outward to ntpq where it's easy to change without perturbing the core code. (That will also reduce C LOC in favor of increasing Python LOC, which is always good for maintainability.) What I will do, unless you tell me there's something really important about those three wired-in order tables in ntp_control.c, is move them to ntpq. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel