[GIT PULL] Rust timekeeping for v6.18

[GIT PULL] Rust timekeeping for v6.18

[Andreas Hindborg]

Hi Miguel,

Please pull these changes for the rust timekeeping subsystem.

This PR consists of three main parts:

 - Additional functionality for `HrTimer` that allows use of operations
   that can only be executed in timer callback context, or with
   exclusive access to a timer that is not armed.

 - Arithmetic operations for `Instant` and `Delta`.

 - A few other minor updates.

While these changes will benefit everyone in the long run, they have a
near future user in rvkms. The changes has been in linux-next for at
least a week.

The following changes since commit b320789d6883cc00ac78ce83bccbfe7ed58afcf0:

  Linux 6.17-rc4 (2025-08-31 15:33:07 -0700)

are available in the Git repository at:

  ssh://github.com/Rust-for-Linux/linux.git tags/rust-timekeeping-v6.18

for you to fetch changes up to 4521438fb076f8a6a52f45b0e508f6ef10ac0c49:

  rust: time: Implement basic arithmetic operations for Delta (2025-09-04 16:56:48 +0200)

Best regards,
Andreas

----------------------------------------------------------------
Rust timekeeping changes for v6.18

 - Add methods on `HrTimer` that can only be called with exclusive access to an
   unarmed timer, or form timer callback context.

 - Add arithmetic operations to `Instant` and `Delta`.

 - Add a few convenience and access methods to `HrTimer` and `Instant`.

----------------------------------------------------------------
Lyude Paul (9):
      rust: hrtimer: Document the return value for HrTimerHandle::cancel()
      rust: hrtimer: Add HrTimerInstant
      rust: hrtimer: Add HrTimer::raw_forward() and forward()
      rust: hrtimer: Add HrTimerCallbackContext and ::forward()
      rust: hrtimer: Add forward_now() to HrTimer and HrTimerCallbackContext
      rust: time: Add Instant::from_ktime()
      rust: hrtimer: Add HrTimer::expires()
      rust: time: Implement Add<Delta>/Sub<Delta> for Instant
      rust: time: Implement basic arithmetic operations for Delta

 rust/kernel/time.rs                 | 163 +++++++++++++++++++++++++++++++++++-
 rust/kernel/time/hrtimer.rs         | 152 ++++++++++++++++++++++++++++++++-
 rust/kernel/time/hrtimer/arc.rs     |   9 +-
 rust/kernel/time/hrtimer/pin.rs     |   9 +-
 rust/kernel/time/hrtimer/pin_mut.rs |  12 ++-
 rust/kernel/time/hrtimer/tbox.rs    |   9 +-
 6 files changed, 344 insertions(+), 10 deletions(-)

Re: [GIT PULL] Rust timekeeping for v6.18

[Miguel Ojeda]

On Fri, Sep 19, 2025 at 1:46 PM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>
>  - Additional functionality for `HrTimer` that allows use of operations
>    that can only be executed in timer callback context, or with
>    exclusive access to a timer that is not armed.

Should I use this one or the bullet from the tag itself?

(For future PRs, please avoid duplicating the summary, i.e. the part
that goes outside the tag message should generally be about meta
comments that should not go into the repository, like the linux-next
note.)

By the way, I noticed a commit without a commit message apart from the
title and tags -- for future PRs, please try to always ensure there is
some context, especially explaining why something is added:

    ac0a7bd27f65 ("rust: hrtimer: Add forward_now() to HrTimer and
HrTimerCallbackContext")

Thanks!

Cheers,
Miguel

Re: [GIT PULL] Rust timekeeping for v6.18

[Andreas Hindborg]

"Miguel Ojeda" <miguel.ojeda.sandonis@gmail.com> writes:

> On Fri, Sep 19, 2025 at 1:46 PM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>>
>>  - Additional functionality for `HrTimer` that allows use of operations
>>    that can only be executed in timer callback context, or with
>>    exclusive access to a timer that is not armed.
>
> Should I use this one or the bullet from the tag itself?

I would suggest you use the info in the tag.

> (For future PRs, please avoid duplicating the summary, i.e. the part
> that goes outside the tag message should generally be about meta
> comments that should not go into the repository, like the linux-next
> note.)

I am actually a bit confused as to what information you prefer in the
tag and what you prefer in the pull request message itself. I would
appreciate a reminder to use as a guideline. They seem redundant to me,
which is why I used an empty tag last cycle.

>
> By the way, I noticed a commit without a commit message apart from the
> title and tags -- for future PRs, please try to always ensure there is
> some context, especially explaining why something is added:
>
>     ac0a7bd27f65 ("rust: hrtimer: Add forward_now() to HrTimer and
> HrTimerCallbackContext")

Thanks, I missed that somehow. Usually `check_patch.pl` will complain
for this kind of thing.


Best regards,
Andreas Hindborg

Re: [GIT PULL] Rust timekeeping for v6.18

[Miguel Ojeda]

On Mon, Sep 22, 2025 at 10:22 AM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>
> I am actually a bit confused as to what information you prefer in the
> tag and what you prefer in the pull request message itself. I would
> appreciate a reminder to use as a guideline. They seem redundant to me,
> which is why I used an empty tag last cycle.

As I mentioned, anything that you consider that should not be in the
merge commit should be outside. Typically, mentions about linux-next,
expected conflicts, links to test merges and resolutions, any other
warnings the puller should know about and so on and so forth.

That is why they aren't redundant -- like we do in patches, one part
is the commit message and the part below the `---` line (or the cover
letter) are usually meta comments such as the changelog.

Of course, duplicating the tag message in the email message gets
confusing, which is why I asked, because then I am not sure which one
you want me to put in the merge commit.

Please refer to other PRs for examples, e.g.

    https://lore.kernel.org/all/20250605025400.244965-1-ojeda@kernel.org/

Thanks!

Cheers,
Miguel

Re: [GIT PULL] Rust timekeeping for v6.18

[Miguel Ojeda]

On Fri, Sep 19, 2025 at 1:46 PM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>
> Please pull these changes for the rust timekeeping subsystem.

Merged into `rust-next` -- thanks!

Cheers,
Miguel