Amar Takhar <v...@darkbeer.org>: > No idea but I do not favour the idea of removing features to avoid adding > workarounds. That's worse than adding utmp support back in. I think it's a > reasonable solution for > > If it was more than touching a single file and adding a couple of ifdefs it > would be a strong argument but for this case it's better to add it back in.
Please note that this code was conditioned out at the time of the fork, and is therefore probably still disabled in Classic. I had to repair it before it would compile. So we wouldn't be removing a feature, exactly, if we entirely dropped it - just agreeing with whoever last touched it before me that it was a failed experiment. I would be OK with either (a) leaving it as is, with a tweak to not try building it on OpenBSD, or (b) dropping it entirely. I would be opposed to adding, or restoring, a non-POSIX workaround. In general, I value reducing the codebase complexity more than maintaining marginal and semi-broken features of this kind. I came very near just quietly dropping this one, but my general policy is to save what POSIX can save even if I'm dubious about its usefulness. When Hal says: >We could easily and cleanly bypass the code that uses utmpx. That would >screwup accounting if time stepped by more than a second. I'm not entirely clear on the referent of "that". The *bypass* would screw up accounting if time stepped by more than a second? -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel