Re: [PATCH 9/9] rust: time: add ktime_get_real_seconds

[Andreas Hindborg]

FUJITA Tomonori <tomo@xxxxxxxxxxxx> writes:

> On Thu, 27 Aug 2026 15:39:53 +0200
> Andreas Hindborg <a.hindborg@xxxxxxxxxx> wrote:
>
>> "Mike Lothian" <mike@xxxxxxxxxxxxxx> writes:
>> 
>>> Reading an `Instant<RealTime>` is the wrong tool for a caller that only
>>> wants a calendar time in seconds: it takes a full nanosecond timestamp and
>>> then needs a 64-bit division to get back to what the timekeeping core
>>> already maintains as a plain seconds field.
>>>
>>> Wrap `ktime_get_real_seconds()`, which is that field. Document the property
>>> that matters at the call site and that the type cannot express: the value
>>> follows CLOCK_REALTIME, so it is not monotonic and can move in either
>>> direction.
>> 
>> We recently added the concept of `TimeUnit`. For now it is exposed via
>> `Delta<U: TimeUnit>`. We could extend this to `Instant` as well to have
>> a seconds based `Instant`.
>
> I don't think that is a good idea.
>
> `Instant` is a point in time that exists to produce a `Delta`: `now()` is its
> only constructor,

`Instant` is a point in time. `ktime_get_real_seconds` return a point in
time. Whether the constructor is `Delta::now` or should be
`Instant::now` could be discussed.

> and what you do with it is `elapsed()`

I don't see the issue with `Instant<RealSeconds>::elapsed()`. You would
get a duration of seconds that has elapsed since the instant? Of course
you get all the inaccuracy that comes with using seconds resolution.

> or `Instant -
> Instant`.

Same.

> So a seconds based `Instant` has to define what `Instant - Instant`
> returns,

A `Delta<Seconds>` would be the obvious choice? I perfer `Seconds` and
`NanoSeconds`, but the abbreviated pattern is already prevalent, so
probably best to go with that.

> and `Delta<Sec>` would have no consumer.

True, but OK I guess.

> Every interface that takes a
> span takes a `Delta<Nsec>`: `fsleep()`, `udelay()`, `HrTimer::forward()`,
> `read_poll_timeout()`.

That is fine. Those APIs do not have to take `Delta<Seconds>`, they can
keep taking `Delta<Nsec>`

> `Delta` also already treats seconds as an input format
> rather than a unit, since `Delta::from_secs()` returns a
> `Delta<Nsec>`.

That is fine. In the context of `Delta::from_secs` the argument is a
duration. `Instant<Seconds>` is a logically different concept. It is a
point in time, not a duration.

> That is
> the difference from `Delta<Jiffy>`, which earned a type because the C side takes
> jiffies at the boundary and the conversion is lossy; `time64_t` is an `i64` and
> seconds to nanoseconds is exact.

Yes, we made `Delta<Jiffy>` from a need to pass a jiffy based duration
to C code. That should not prevent us from having a seconds based `Instant`.

If you are concerned about the dead code in a seconds based `Delta`, we
can gate the impls.

> And that is not how `ktime_get_real_seconds()` is used in the first place. Its
> callers need a calendar value in seconds because something outside the kernel
> fixes the format: an on-disk field, a value passed to firmware, or a userspace
> ABI field. Many of them compare it against an expiry time that came from the
> wire or from disk.

Again, sure, that is why we originally introduced these types. But I
don't think we should gate our time representing types on the rationale
of the first use case. We should represent points in time and duration
of time with a single set of types.

> Does that make sense?

I think I understand your concern, but I do not share it.

I would appreciate others to chime in on this - in either direction. How
should we represent time in general.


Best regards,
Andreas Hindborg