[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <877cat32kz.fsf@somnus>
Date: Mon, 30 Sep 2024 11:36:44 +0200
From: Anna-Maria Behnsen <anna-maria@...utronix.de>
To: Andreas Hindborg <a.hindborg@...nel.org>, Miguel Ojeda
<ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, Frederic
Weisbecker <frederic@...nel.org>, Thomas Gleixner <tglx@...utronix.de>
Cc: Andreas Hindborg <a.hindborg@...nel.org>, Boqun Feng
<boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, Björn
Roy Baron
<bjorn3_gh@...tonmail.com>, Benno Lossin <benno.lossin@...ton.me>, Alice
Ryhl <aliceryhl@...gle.com>, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 00/14] hrtimer Rust API
Hi Andreas,
Andreas Hindborg <a.hindborg@...nel.org> writes:
> Hi!
>
> This series adds support for using the `hrtimer` subsystem from Rust code.
>
> I tried breaking up the code in some smaller patches, hopefully that will
> ease the review process a bit.
>
> The major change in this series is the use of a handle to carry ownership
> of the callback target. In v1, we used the armed timer to carry ownership
> of the callback target. This caused issues when the live timer became the
> last owner of the callback target, because the target would be dropped in
> timer callback context. That is solved by using a handle instead.
>
> A request from Thomas on v1 was to add a more complete API. While I did add
> more features, we are still missing some. In the interest of getting the
> patches on list prior to LPC 2024, I am leaving out the following planned
> features:
>
> - hrtimer_sleeper, schedule_hrtimeout, hrtimer_nanosleep and friends
> - introspection functions:
> - try_cancel
> - get_remaining
> - active
> - queued
> - callback_running
> - hrtimer_forward
> - access to timer callback target through timer handle
Regarding the API: I had a closer look at it after the discussion during
LPC. It's possible to change the API (prevent setting the mode in start
as well), but it is not as straight forward, as it originally seems to
be. So this will take some time to be changed completely.
But what we will do in short term is to create htimer_setup(). This will
do the job of hrtimer_init() but expand it by the argument of the
hrtimer function callback.
This is just an information update for you. So you can proceed right now
with the current API and we keep you in the loop for further changes.
Thanks,
Anna-Maria
Powered by blists - more mailing lists