[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z7hjrzyVNd5BIcEy@pavilion.home>
Date: Fri, 21 Feb 2025 12:29:51 +0100
From: Frederic Weisbecker <frederic@...nel.org>
To: Benno Lossin <benno.lossin@...ton.me>
Cc: Andreas Hindborg <a.hindborg@...nel.org>,
Miguel Ojeda <ojeda@...nel.org>,
Anna-Maria Behnsen <anna-maria@...utronix.de>,
Thomas Gleixner <tglx@...utronix.de>,
Danilo Krummrich <dakr@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
Lyude Paul <lyude@...hat.com>, Guangbo Cui <2407018371@...com>,
Dirk Behme <dirk.behme@...il.com>,
Daniel Almeida <daniel.almeida@...labora.com>,
Tamir Duberstein <tamird@...il.com>, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 02/14] rust: hrtimer: introduce hrtimer support
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@...nel.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.
Powered by blists - more mailing lists