Re: [PATCH v8 02/14] rust: hrtimer: introduce hrtimer support

[Frederic Weisbecker <frederic@kernel.org>]

Le Thu, Feb 20, 2025 at 11:46:10PM +0000, Benno Lossin a écrit :
> On 18.02.25 14:27, Andreas Hindborg wrote:
> > This patch adds support for intrusive use of the hrtimer system. For now,
> > only one timer can be embedded in a Rust struct.
> > 
> > The hrtimer Rust API is based on the intrusive style pattern introduced by
> > the Rust workqueue API.
> > 
> > Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
> > ---
> >  rust/kernel/time.rs         |   2 +
> >  rust/kernel/time/hrtimer.rs | 312 ++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 314 insertions(+)
> > 
> > diff --git a/rust/kernel/time.rs b/rust/kernel/time.rs
> > index 87e47f2f5618d..2cf365cfb412e 100644
> > --- a/rust/kernel/time.rs
> > +++ b/rust/kernel/time.rs
> > @@ -10,6 +10,8 @@
> > 
> >  use core::convert::Into;
> > 
> > +pub mod hrtimer;
> > +
> >  /// The number of nanoseconds per millisecond.
> >  pub const NSEC_PER_MSEC: i64 = bindings::NSEC_PER_MSEC as i64;
> > 
> > diff --git a/rust/kernel/time/hrtimer.rs b/rust/kernel/time/hrtimer.rs
> > new file mode 100644
> > index 0000000000000..a6332924efabd
> > --- /dev/null
> > +++ b/rust/kernel/time/hrtimer.rs
> > @@ -0,0 +1,312 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +//! Intrusive high resolution timers.
> > +//!
> > +//! Allows running timer callbacks without doing allocations at the time of
> > +//! starting the timer. For now, only one timer per type is allowed.
> > +//!
> > +//! # Vocabulary
> > +//!
> > +//! States:
> > +//!
> > +//! * Stopped
> > +//! * Running
> > +//!
> > +//! Operations:
> > +//!
> > +//! * Start
> > +//! * Cancel
> > +//! * Stop
> > +//! * Restart
> > +//!
> > +//! Events:
> > +//!
> > +//! * Expire
> > +//!
> > +//! ## State Diagram
> > +//!
> > +//! ```text
> > +//!                  <-- Stop ----
> > +//!                  <-- Cancel --
> > +//!                  --- Start -->
> > +//!        +---------+        +---------+
> > +//!   O--->| Stopped |        | Running |---o
> > +//!        +---------+        +---------+   |
> > +//!                                  ^      |
> > +//!                  <- Expire --    |      |
> > +//!                                  o------o
> > +//!                                   Restart
> > +//! ```
> > +//!
> > +//! A timer is initialized in the **stopped** state. A stopped timer can be
> > +//! **started** with an **expiry** time. After the timer is started, it is
> > +//! **running**. When the timer **expires**, the timer handler is executed.
> > +//! After the handler has executed, the timer may be **restarted** or
> > +//! **stopped**. A running timer can be **canceled** before it's handler is
> 
> This confuses me a bit, in the other thread you wrote that the handler
> decides if the timer should restart or be stopped. But What happens when
> I call `cancel` on the `HrTimerHandle` while the handler is running, but
> finishes shortly after with a restart request? Will it be canceled?
> 
> I also have a bit of a wording issue with "the timer is running" IIUC,
> this means that the timer subsystem keeps track of the expiry time and
> when the time is elapsed, it fires the code that you registered prior.
> At first, I thought that "the timer is running" meant that the
> registered code is running. Maybe we should have two different terms for
> that? I personally would prefer "active timer" for "the timer subsystem
> is currently tracking the time and when it is elapsed, it will run the
> code" and "running timer" for "the timer's expiry time has elapsed and
> the timer callback is currently being executed".

Good point. "Running" in the hrtimer terminology is usually to
describe a running callback and not just an elapsing (or say started) timer.

I would rather have:

Stopped: initialized but not started, or cancelled, or not restarted
Started: initialized and started or restarted
Running: executing the callback

Thanks.