In article <[email protected]>, [email protected] (Danny Mayer) wrote:
> Joe Gwinn wrote: > > Status code values fixed. > > > > At 10:47 PM -0400 3/15/09, Danny Mayer wrote: > >> Joseph Gwinn wrote: > >>> Hmm. OK, but I think that we've kind of run off the rails. Let me > >>> summarize: > >>> 1. Sun Microsystems' current behavior is not the issue, as I'm loading > >>> old software from an old CD onto old computer hardware, hardware that > >>> cannot support a newer version of Solaris than v9. > >>> One of these old Solaris boxes did work with NTPv3 running an even > >>> older > >> > version of Solaris, with no 9514 codes, deepening the mystery. > >> > > >> > >> The trouble here is that those codes are *very likely* likely to have > >> changed between V3 and V4 since there was a large rewrite between the > >> two. That's why looking at the source code is necessary to get you the > >> help you need. > > > > As discussed in my other reply, mutating codes is a blunder. It's a > > good news bad news thing. The good news is that NTP has succeeded on an > > unimagined scale. The bad news is that because of that scale, one must > > be *very* respectful of NTP's existing base, and it can be constraining. > > > > You won't get any argument from us. However, Dave Mills is responsible > for these codes and we haven't been able to get him to agree to not > change the test code numbers and to use new ones if he needs more and > just not reuse the old ones. He has good reasons for changing the tests > but changing the meaning of the same code is harder to fathom. His view > is that these are internal tests but when you are trying to track down a > problem with your ntp daemon, it's important to know what they mean. These codes are *not* internal only. They are documented in RFC-1305, Appendix B, which is also pointed to by the NTPv4 documentation <http://www.eecis.udel.edu/~mills/ntp/html/monopt.html>. These codes are quite public. > >> > The fact that this obsolete system can most likely support NTPv4 is > >>> worth investigation, though. > >>> > >>> 2. I think that what's happening is that I'm doing something dumb, and > >>> I bet that there is no real difference in how NTPv3 or NTPv4 would react > >>> to this faux pas, whatever it turns out to be. Nor is source code > >>> research needed or requested. > >>> 3. The original question was how to interpret a specific status code, > >>> 9514. I read the explanation in the documentation, but became no wiser > >>> for it. Thus my question. > >> > >> Which is why you need to look at the source code. Documentation isn't > >> always clear or definitive but the source code will tell you. > > > > It simply cannot be required to read source code to get the definitions > > of status codes, even if the documentation has to give one definition > > per NTP version. NTP is used on hundreds of millions of computers. Are > > we expecting that every time someone gets an unexpected code they either > > have to read the source code, or pay someone to read it for them? I'm > > sorry, but that cannot work. > > > > I agree, but I'm not the person you need to persuade. In V4 the flash > codes are listed in libntp/statestr.c. I don't know about V3. While given the pointer I may well look, the fundamental issue remains. > You may also be amused by this sync code: > { CTL_SST_TS_WRSTWTCH, "sync_wristwatch" }, Heh. Hairy wrist required. Joe Gwinn _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
