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

On Thu, 27 Aug 2026 15:39:53 +0200
Andreas Hindborg [off-list ref] wrote:

"Mike Lothian" [off-list ref] writes:

quoted

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, and what you do with it is `elapsed()` or `Instant -
Instant`. So a seconds based `Instant` has to define what `Instant - Instant`
returns, and `Delta<Sec>` would have no consumer. Every interface that takes a
span takes a `Delta<Nsec>`: `fsleep()`, `udelay()`, `HrTimer::forward()`,
`read_poll_timeout()`. `Delta` also already treats seconds as an input format
rather than a unit, since `Delta::from_secs()` returns a `Delta<Nsec>`. 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.

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.

Does that make sense?