[PATCH v2] time: Add TIME_MONOTONIC, TIME_ACTIVE, and TIME_THREAD_ACTIVE

[Adhemerval Zanella Netto]

On 25/11/25 10:43, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>> On 25/11/25 05:35, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>>> The TIME_MONOTONIC maps to POSIX's CLOCK_MONOTONIC, TIME_ACTIVE to
>>>> CLOCK_PROCESS_CPUTIME_ID, and TIME_THREAD_ACTIVE to
>>>> CLOCK_THREAD_CPUTIME_ID.
>>>>
>>>> No Linux specific timer are added as extension.
>>>
>>> I think we should come up with some general transformation of the clock
>>> ID values.  It would help us if WG14 lifted the requirement that clock
>>> IDs must be positive integers.  The interfaces they defined merely
>>> require that valid clock IDs are not zeros.  Once negative values are
>>> permitted, we only have to special-case the zero value.  New clocks then
>>> are just a matter of kernel support and defining the appropriate
>>> constants in a header file.
>>
>> At least for Linux/POSIX we can currently assume a direct mapping between
>> C timebase and POSIX clockid.  What I am not sure is if we should add
>> GNU extensions to transform between clocks, like the timebase_to_clockid
>> and clockid_to_timebase proposed early for this feature.
> 
> The issue is that CLOCK_REALTIME is zero, WG14 decided to ban this
> value, and baked this decision firmly into the interface.  So we cannot
> have an identical mapping or even a 1:1 mapping.  We can find a Linux
> clock 𝕮 that is unlikely to be a WG14 clock, ever (like a device clock
> for standard input), and then do this:
> 
>   CLOCK_REALTIME → 1
>   𝕮 → 0
>   rest gets mapped as conveniently as possible.
> 
> The last line gets easier if we can use the full int range, excluding
> zero.

I am not following what why it would be an issue of adding the TIME_* clock
now.  We can define the TIME_* are POSIX clocks plus 1 in practice; and any
new possible clock we can map different if required.