[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87plogp2k4.fsf@kernel.org>
Date: Fri, 04 Oct 2024 12:47:39 +0200
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Anna-Maria Behnsen" <anna-maria@...utronix.de>
Cc: "Miguel Ojeda" <ojeda@...nel.org>, "Alex Gaynor"
<alex.gaynor@...il.com>, "Frederic Weisbecker" <frederic@...nel.org>,
"Thomas Gleixner" <tglx@...utronix.de>, "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
"Anna-Maria Behnsen" <anna-maria@...utronix.de> writes:
> 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! I think we talked about something similar for v1 as well.
BR Andreas
Powered by blists - more mailing lists