[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <203e2439-4bba-4a0a-911b-79c81646a714@lunn.ch>
Date: Thu, 3 Oct 2024 18:09:15 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Boqun Feng <boqun.feng@...il.com>
Cc: FUJITA Tomonori <fujita.tomonori@...il.com>, dirk.behme@...bosch.com,
aliceryhl@...gle.com, netdev@...r.kernel.org,
rust-for-linux@...r.kernel.org, hkallweit1@...il.com,
tmgross@...ch.edu, ojeda@...nel.org, alex.gaynor@...il.com,
gary@...yguo.net, bjorn3_gh@...tonmail.com, benno.lossin@...ton.me,
a.hindborg@...sung.com
Subject: Re: iopoll abstraction
> we cover all the cases, but this is a good starting point. I would put
> the function at kernel::io::poll, but that's my personal preference ;-)
iopoll.h has a few variants. The variant being implemented here can
only be used in thread context where it can sleep. There is also
read_poll_timeout_atomic() which can be used in atomic context, which
uses udelay() rather than sleeping, since you are not allowed to sleep
in atomic context.
So we should keep the naming open to allow for the atomic variant
sometime in the future.
We probably also want a comment that this helper cannot be used in
atomic context.
Do we have a Rust equivalent of might_sleep()?
https://elixir.bootlin.com/linux/v6.12-rc1/source/include/linux/kernel.h#L93
Andrew
Powered by blists - more mailing lists