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

[Mike Lothian]

On Tue, 8 Sep 2026, Andreas Hindborg wrote:
> We should represent points in time and duration of time with a single
> set of types.

On Tue, 8 Sep 2026, FUJITA Tomonori wrote:
> I could not find a user of this in the posted series, including the
> drm/vino v3 one, which looks like it uses `Instant<Monotonic>`
> everywhere.  Where can I see the code that calls this, and what does
> it do with the value?

Sorry, the user wasn't in anything I'd posted when you asked.  It's in
the drm/vino series that sits on top of this one, 7/14 in the new
posting, which I haven't sent yet

The dock has a real-time clock and the DisplayLink driver sets it during
session bring-up.  The message carries the calendar date and time in
broken-down form, so the code takes the seconds, adds a UTC offset that
comes from a module parameter, and works out year, month, day, hour,
minute, second, weekday and day of year.  That's the only use, it's read
once per bring-up and nothing is compared against it

So it's the case you described, Tomonori: the format is fixed outside
the kernel, by the dock's firmware, and what the caller wants is an i64
of seconds since the epoch.  It never gets subtracted from anything, so a
seconds based Instant would only be there to be converted straight back

I don't have a strong view on Instant<Seconds> versus the plain function.
If you two settle on the Instant, I'll respin on it, but I'd rather not
block the rest of rust-core on that, and the function is small enough to
change when the types land

Mike