Re: git: 108de784513d - main - Redefine CLOCK_BOOTTIME to alias CLOCK_MONOTONIC, not CLOCK_UPTIME

On Sun, Jun 2, 2024 at 2:05 PM Olivier Certner <olce@freebsd.org> wrote:

> Hi,
>
> Some food for thought.
>
> Given the (minor?) fallout, I wonder if we should have instead just added
> a distinct numerical value for CLOCK_BOOTTIME, which didn't occur to me
> while doing the review.  This would have the benefit of allowing all these
> 'case' labels to coexist, which makes the interface more predictable and
> thus easier on applications.  The patches below obviously only can cover
> the precise applications that we noticed failed to compile, and not other
> existing ones nor future ones to be written.  I don't see any real drawback
> for such an approach because, to read clock information, applications
> always have to specify the clock ID and, AFAIK, cannot, e.g., request a
> list of clocks and times, where we would have to be careful to output the
> same time for all the aliased clock IDs.
>

Maybe in the future. This issue is completely solved the way that it is now
and I think this is over-engineering. It *WAS* an alias for CLOCK_UPTIME
and now it's an alias for CLOCK_MONOTONIC. When it went in, other minor
changes were also needed, as were changes before it went in. Its semantics
and values are implementation defined. Linux happened to define it to have
a subtly different meaning than their CLOCK_MOTONIC, and when we adopted
it, there was a critical detail I misunderstood. There were at least a
dozen applications that were ported to FreeBSD that needed to have the
#ifdef added in the days before I added the alias, for example. The new
value might have averted this breakage, but it might also have introduced
subtle breakage where a program thought these were distinct that we're not
seeing. It's hard to say if it's a good or bad idea to adopt a value that's
unique to avoid one set of breakage, only to maybe introduce other breakage
which would be harder to detect (things compile, but they misbehave, vs
this solution where compilation may break, but then you know you have the
issue).a

So if you want to drive it, drive the exp run, etc, knock yourself out. But
given the absolutely trivial amount of fallout, I'm on to the hundreds of
more important things that are in my backlog. I consider the problem
solved, unless there's new information. But maybe I'm still feeling burned
out by the 12 months of iteration that it took to fix all the compatibility
issues with something as simple as endian.h.... only to discover 30 months
later a new, different subtle breakage.

Warner


> Thanks.
>
> --
> Olivier Certner
>