On Sat, Feb 6, 2016 at 10:30 AM, Eric S. Raymond <e...@thyrsus.com> wrote:
> 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. > > Supporting the methods in <utmpx.h> does not make sense in a single process embedded RTOS. They won't be available there. I am not discouraging using them on full UNIX systems or finding a workaround when not available but a path for systems where the method doesn't make much sense. I am almost sure they are not part of any of the FACE (opengroup.org/face) POSIX profiles for avionics systems. And I am sure RTEMS doesn't support them. What is this really used for? How could the same goal be achieved in a single process, multi-threaded OS? > 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 >
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
