<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 6, 2016 at 10:30 AM, Eric S. Raymond <span dir="ltr"><<a href="mailto:esr@thyrsus.com" target="_blank">esr@thyrsus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Amar Takhar <<a href="mailto:verm@darkbeer.org">verm@darkbeer.org</a>>:<br>
<span class="">> No idea but I do not favour the idea of removing features to avoid adding<br>
> workarounds.  That's worse than adding utmp support back in.  I think it's a<br>
> reasonable solution for<br>
><br>
> If it was more than touching a single file and adding a couple of ifdefs it<br>
> would be a strong argument but for this case it's better to add it back in.<br>
<br>
</span>Please note that this code was conditioned out at the time of the<br>
fork, and is therefore probably still disabled in Classic. I had to<br>
repair it before it would compile.<br>
<br>
So we wouldn't be removing a feature, exactly, if we entirely dropped<br>
it - just agreeing with whoever last touched it before me that it was<br>
a failed experiment.<br>
<br>
I would be OK with either (a) leaving it as is, with a tweak to not<br>
try building it on OpenBSD, or (b) dropping it entirely.  I would be<br>
opposed to adding, or restoring, a non-POSIX workaround.<br>
<br>
In general, I value reducing the codebase complexity more than maintaining<br>
marginal and semi-broken features of this kind.  I came very near just<br>
quietly dropping this one, but my general policy is to save what POSIX<br>
can save even if I'm dubious about its usefulness.<br>
<span class=""><br></span></blockquote><div><br></div><div>Supporting the methods in <utmpx.h> does not make sense in a single process</div><div>embedded RTOS. They won't be available there. </div><div><br></div><div>I am not discouraging using them on full UNIX systems or finding a workaround</div><div>when not available but a path for systems where the method doesn't make much</div><div>sense.</div><div><br></div><div>I am almost sure they are not part of any of the FACE (<a href="http://opengroup.org/face">opengroup.org/face</a>)</div><div>POSIX profiles for avionics systems. And I am sure RTEMS doesn't support</div><div>them.</div><div><br></div><div>What is this really used for? How could the same goal be achieved in a single </div><div>process, multi-threaded OS?</div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
When Hal says:<br>
<br>
>We could easily and cleanly bypass the code that uses utmpx.  That would<br>
>screwup accounting if time stepped by more than a second.<br>
<br>
</span>I'm not entirely clear on the referent of "that".  The *bypass* would<br>
screw up accounting if time stepped by more than a second?<br></blockquote><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888">--<br>
                <a href="<a href="http://www.catb.org/~esr/" rel="noreferrer" target="_blank">http://www.catb.org/~esr/</a>">Eric S. Raymond</a><br>
</font></span><div class=""><div class="h5">_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@ntpsec.org">devel@ntpsec.org</a><br>
<a href="http://lists.ntpsec.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ntpsec.org/mailman/listinfo/devel</a><br>
</div></div></blockquote></div><br></div></div>