utmpx on OpenBSD.

Joel Sherrill joel at rtems.org
Sat Feb 6 17:06:42 UTC 2016


On Sat, Feb 6, 2016 at 10:30 AM, Eric S. Raymond <esr at thyrsus.com> wrote:

> Amar Takhar <verm at 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 at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160206/2b9dc461/attachment.html>


More information about the devel mailing list