Subject: Re: [PATCH v11 6/8] MAINTAINERS: rust: Add new sections for DELAY/SLEEP and TIMEKEEPING API

From: Boqun Feng <[email-masked]>
Date: Fri, 4 Apr 2025 09:40:06 -0700

On Thu, Apr 03, 2025 at 09:57:45PM +0900, FUJITA Tomonori wrote:
> On Thu, 03 Apr 2025 12:54:40 +0200
> Andreas Hindborg <[email-masked]> wrote:
> 
> >>>> You will need to fix something because patch 2-6 removes `Ktime` ;-)
> >>>
> >>> Yea, but `Instant` is almost a direct substitution, right? Anyway, Tomo
> >>> can send a new spin and change all the uses of Ktime, or I can do it. It
> >>> should be straight forward. Either way is fine with me.
> >>
> >> `Delta`? Not `Instant`.
> > 
> > It depends. Current hrtimer takes `Ktime` and supports
> > `HrTimerMode::Absolute` and `HrTimerMode::Relative`. With `Delta` and
> > `Instant` we should take `Instant` for `HrTimerMode::Absolute` and
> > `Delta` for `HrTimerMode::Relative`. The API needs to be modified a bit
> > to make that work though. Probably we need to make the start function
> > generic over the expiration type or something.
> > 

If we make `HrTimerMode` a trait:

    pub trait HrTimerMode {
        type Expires; /* either Delta or Instant */
    }

and `HrTimerPointer` generic over `HrTimerMode`:

    pub trait HrTimerPointer<Mode: HrTimerMode> {
        fn start(self, expires: Mode::Expires) -> HrTimerHandler<Mode>
    }

then we can disallow that a Relative timer accidentally uses an Instant
or an Absolute timer accidentally uses an Delta. Of course a few other
places need to be generic, but the end result looks pretty good to me.

Regards,
Boqun

> > If you want to, you can fix that. If not, you can use `Instant` for the
> > relative case as well, and we shall interpret it as duration. Then I
> > will fix it up later. Your decision.
> > 
> >> All Ktime in hrtimer are passed to hrtimer_start_range_ns(), right?
> > 
> > Yes, that is where they end up.
> 
> Ah, I found that __hrtimer_start_range_ns() handles ktime_t
> differently in HRTIMER_MODE_REL mode.
> 
> As you said, looks like the API needs to be updated and I think that
> it's best to leave that to you. I'll just use `Instant` for all cases.
> 
>