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

FUJITA Tomonori [off-list ref] writes:

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

quoted

"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,

`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