Re: [PATCH v3 2/2] rust: use Delta and a Jiffies newtype for timeouts and delays

On Mon, 20 Jul 2026 11:16:06 -0700
John Stultz <[email protected]> wrote:

> On Mon, Jul 20, 2026 at 2:48 AM FUJITA Tomonori <[email protected]> wrote:
>> On Sat, 18 Jul 2026 16:20:10 +0100
>> "Gary Guo" <[email protected]> wrote:
>> > I wonder if we should have time types being generic over units. So you can have
>> > `Delta<Nsec>` and `Delta<Jiffy>` and `Instant<Nsec>`, `Instant<Jiffy>`, with the
>> > generic default being set to `Nsec`.
>> >
>> >     Delta::new(42) // Delta<Nsec>
>> >     Delta::new_jiffies(42) // Delta<Jiffy>
>> >
>> > Thoughts?
>>
>> I think making Delta generic over the time unit makes sense; Delta
>> <Nsec> and Delta<Jiffy>.
>>
>> However, I don't think making Instant generic over the time unit is a
>> good idea, even though it clearly is for Delta.
>>
>> Instant is already generic over ClockSource, and jiffies is not a
>> clock source: it has no clockid_t, it is read via get_jiffies_64()
>> rather than ktime_get(), and it cannot be armed through hrtimer. That
>> leaves two ways to force a jiffies Instant, both looks wrong:
> 
> I read the above and thought, "but jiffies is a clocksource":
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/time/jiffies.c#n21
> 
> And then I realized there has been some unfortunate naming overlap,
> where it seems the rust ClockSource seems to map to the clockid_t, not
> to the clocksource concept that Linux uses to abstract the hardware
> counter used as a source of time (for the majority of the clockids).
> 
> Very much a bikeshed request, but is it too late to rename this to
> ClockID or something? So there is maybe less confusion when reading
> across C and Rust code?

Ah, I misunderstood. Thanks for the pointer!

You're right; the trait carries the clockid_t, not the hardware
clocksource. It's not too late at all; I'll rename ClockSource to
ClockId.