From: Christian Schrefl <chrisi.schrefl@gmail.com>
To: Daniel Almeida <daniel.almeida@collabora.com>,
Alice Ryhl <aliceryhl@google.com>
Cc: Boqun Feng <boqun.feng@gmail.com>,
ojeda@kernel.org, alex.gaynor@gmail.com, gary@garyguo.net,
bjorn3_gh@protonmail.com, benno.lossin@proton.me,
a.hindborg@kernel.org, tmgross@umich.edu,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] rust: irq: add support for request_irq()
Date: Thu, 15 May 2025 19:17:05 +0200 [thread overview]
Message-ID: <42820306-3a94-4c47-be9b-c3f89de34866@gmail.com> (raw)
In-Reply-To: <3753EBEB-8538-403A-BEFC-768390EB2D9E@collabora.com>
Hi Daniel
On 14.05.25 4:44 PM, Daniel Almeida wrote:
> Hi Alice,
>
>> On 23 Jan 2025, at 06:07, Alice Ryhl <aliceryhl@google.com> wrote:
>>
>> On Thu, Jan 23, 2025 at 8:18 AM Boqun Feng <boqun.feng@gmail.com> wrote:
>>>
>>> On Wed, Jan 22, 2025 at 01:39:30PM -0300, Daniel Almeida wrote:
>>>> Add support for registering IRQ handlers in Rust.
>>>>
>>>> IRQ handlers are extensively used in drivers when some peripheral wants to
>>>> obtain the CPU attention. Registering a handler will make the system invoke the
>>>> passed-in function whenever the chosen IRQ line is triggered.
>>>>
>>>> Both regular and threaded IRQ handlers are supported through a Handler (or
>>>> ThreadedHandler) trait that is meant to be implemented by a type that:
>>>>
>>>> a) provides a function to be run by the system when the IRQ fires and,
>>>>
>>>> b) holds the shared data (i.e.: `T`) between process and IRQ contexts.
>>>>
>>>> The requirement that T is Sync derives from the fact that handlers might run
>>>> concurrently with other processes executing the same driver, creating the
>>>> potential for data races.
>>>>
>>>> Ideally, some interior mutability must be in place if T is to be mutated. This
>>>> should usually be done through the in-flight SpinLockIrq type.
>>>>
>>>> Co-developed-by: Alice Ryhl <aliceryhl@google.com>
>>>> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
>>>> Signed-off-by: Daniel Almeida <daniel.almeida@collabora.com>
>>>> ---
>>>>
>>>> Changes from v1:
>>>>
>>>> - Added Co-developed-by tag to account for the work that Alice did in order to
>>>> figure out how to do this without Opaque<T> (Thanks!)
>>>> - Removed Opaque<T> in favor of plain T
>>>
>>> Hmmm...
>>>
>>> [...]
>>>
>>>> +#[pin_data(PinnedDrop)]
>>>> +pub struct Registration<T: Handler> {
>>>> + irq: u32,
>>>> + #[pin]
>>>> + handler: T,
>>>
>>> I think you still need to make `handler` as `!Unpin` because compilers
>>> can assume a `&mut T` from a `Pin<&mut Registration>`, am I missing
>>> something here?
>>
>> The current version operates under the assumption that PhantomPinned
>> is enough. But I'm happy to add Aliased here.
>>
>> Alice
>
> Aliased? What is this? I can’t find that trait or type anywhere.
Aliased was a name previously considered for `UnsafePinned` [0].
I believe that was what Alice referred to here.
Just marking the type as !Unpin should be fine on current
Rust versions, but on some future rust versions `UnsafePinned`
might be the only way to make this sound.
[0]: https://lore.kernel.org/rust-for-linux/D9VBVURZLSNT.4BTQQ8UCTGPJ@kernel.org/
Cheers
Christian
next prev parent reply other threads:[~2025-05-15 17:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <u-vC1KbeOK3Fd2PClzinb8LmqS_dntOW-pOSmZIFWotCZeTOg30xR_GYUc4oReAKZeuuu7ZaXWzfeTkpGMlr0A==@protonmail.internalid>
2025-01-22 16:39 ` Daniel Almeida
2025-01-23 7:17 ` Boqun Feng
2025-01-23 9:07 ` Alice Ryhl
2025-05-14 14:44 ` Daniel Almeida
2025-05-15 17:17 ` Christian Schrefl [this message]
2025-01-23 16:00 ` Christian Schrefl
2025-01-23 16:27 ` Daniel Almeida
2025-01-23 17:09 ` Christian Schrefl
2025-03-04 13:05 ` Andreas Hindborg
2025-02-10 8:41 ` Daniel Almeida
2025-02-10 16:41 ` Guangbo Cui
2025-03-04 13:11 ` Andreas Hindborg
2025-03-04 13:43 ` Andreas Hindborg
2025-03-04 16:48 ` Daniel Almeida
2025-03-17 14:58 ` Alice Ryhl
2025-05-09 13:58 ` Daniel Almeida
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42820306-3a94-4c47-be9b-c3f89de34866@gmail.com \
--to=chrisi.schrefl@gmail.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=daniel.almeida@collabora.com \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®