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

[Boqun Feng <boqun@kernel.org>]

On Fri, Oct 30, 2026 at 07:05:02PM +0900, FUJITA Tomonori wrote:
> On Fri, 30 Oct 2026 07:57:50 +0000
> Mike Lothian <mike@fireburn.co.uk> wrote:
> 
> > 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

Even that, I think Instant<Sec> would still be more clear than returning
an i64. Also regarding Tomo's concern:

| So a seconds based `Instant` has to define what `Instant - Instant`
| returns, and `Delta<Sec>` would have no consumer.

We can probably only impl ops::Sub for Instant<C, NSec>, then we don't
have to deal with `Delta<Sec>` until there is a user. (We probably want
to avoid a from_ktime() for Instant<Sec> as well, so separate impl
blocks make sense).

> 
> Right, you only need an i64 of seconds since the epoch and do no
> arithmetic or comparison on it. A type is useful when it guards those
> operations, and there are none here. So the plain function is fine

The way I see it is from kernel::time perspective, we still want to make
sure the APIs are still in the same abstraction layer, a
ktime_get_real_seconds() co-exists with Instant::now() as the public
interface layer breaks that in my opinion. And the generic type
parameter should be flexible enough to avoid introduce anything we don't
have a user yet.

Thoughts?

Regards,
Boqun

> with me. If a caller that needs them shows up later, we can add a type
> then.