From: Danilo Krummrich <dakr@kernel.org>
To: Benno Lossin <lossin@kernel.org>
Cc: gregkh@linuxfoundation.org, rafael@kernel.org, ojeda@kernel.org,
alex.gaynor@gmail.com, boqun.feng@gmail.com, gary@garyguo.net,
bjorn3_gh@protonmail.com, benno.lossin@proton.me,
a.hindborg@kernel.org, aliceryhl@google.com, tmgross@umich.edu,
chrisi.schrefl@gmail.com, rust-for-linux@vger.kernel.org,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>
Subject: Re: [PATCH 1/3] rust: completion: implement initial abstraction
Date: Thu, 12 Jun 2025 12:47:29 +0200 [thread overview]
Message-ID: <aEqwQYJdbVSNA7mr@pollux> (raw)
In-Reply-To: <DAKE8OYKXUWH.1NRVGV5IKW7I9@kernel.org>
On Thu, Jun 12, 2025 at 09:58:30AM +0200, Benno Lossin wrote:
> On Tue Jun 3, 2025 at 10:48 PM CEST, Danilo Krummrich wrote:
> > +/// # Examples
> > +///
> > +/// ```
> > +/// use kernel::sync::{Arc, Completion};
> > +/// use kernel::workqueue::{self, impl_has_work, new_work, Work, WorkItem};
> > +///
> > +/// #[pin_data]
> > +/// struct MyTask {
> > +/// #[pin]
> > +/// work: Work<MyTask>,
>
> Can we maybe add a dummy value like `Mutex<i32>` here that the task
> changes, so we can print the value of it below (after waiting for the
> task)?
Sure, but I don't think it improves the example a lot. It adds more code that
may be more distracting than helpful.
> > +/// #[pin]
> > +/// done: Completion,
> > +/// }
> > +///
> > +/// impl_has_work! {
> > +/// impl HasWork<Self> for MyTask { self.work }
> > +/// }
> > +///
> > +/// impl MyTask {
> > +/// fn new() -> Result<Arc<Self>> {
> > +/// let this = Arc::pin_init(pin_init!(MyTask {
> > +/// work <- new_work!("MyTask::work"),
> > +/// done <- Completion::new(),
> > +/// }), GFP_KERNEL)?;
> > +///
> > +/// let _ = workqueue::system().enqueue(this.clone());
> > +///
> > +/// Ok(this)
> > +/// }
> > +///
> > +/// fn wait_for_completion(&self) {
> > +/// self.done.wait_for_completion();
> > +///
> > +/// pr_info!("Completion: task complete\n");
> > +/// }
> > +/// }
> > +///
> > +/// impl WorkItem for MyTask {
> > +/// type Pointer = Arc<MyTask>;
> > +///
> > +/// fn run(this: Arc<MyTask>) {
> > +/// // process this task
> > +/// this.done.complete_all();
> > +/// }
> > +/// }
> > +///
> > +/// let task = MyTask::new()?;
> > +/// task.wait_for_completion();
> > +/// # Ok::<(), Error>(())
> > +/// ```
> > +#[pin_data]
> > +pub struct Completion {
> > + #[pin]
> > + inner: Opaque<bindings::completion>,
> > +}
> > +
> > +impl Completion {
> > + /// Create an initializer for a new [`Completion`].
> > + pub fn new() -> impl PinInit<Self> {
> > + pin_init!(Self {
> > + inner <- Opaque::ffi_init(|slot: *mut bindings::completion| {
> > + // SAFETY: `slot` is a valid pointer to an uninitialized `struct completion`.
> > + unsafe { bindings::init_completion(slot) };
> > + }),
> > + })
> > + }
> > +
> > + fn as_raw(&self) -> *mut bindings::completion {
> > + self.inner.get()
> > + }
> > +
> > + /// Signal all tasks waiting on this completion.
> > + ///
> > + /// This method wakes up all tasks waiting on this completion; after this operation the
> > + /// completion is permanently done.
> > + pub fn complete_all(&self) {
> > + // SAFETY: `self.as_raw()` is a pointer to a valid `struct completion`.
> > + unsafe { bindings::complete_all(self.as_raw()) };
> > + }
> > +
> > + /// Wait for completion of a task.
> > + ///
> > + /// This method waits for the completion of a task; it is not interruptible and there is no
>
> I personally would write:
>
> s/waits for/blocks on/
>
> But if `wait` is the more common kernel term then let's go with your
> version instead.
I don't think either is more common in general, but the C code and the existing
documentation all use "wait for".
next prev parent reply other threads:[~2025-06-12 10:47 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-03 20:48 [PATCH 0/3] Fix race condition in Devres Danilo Krummrich
2025-06-03 20:48 ` [PATCH 1/3] rust: completion: implement initial abstraction Danilo Krummrich
2025-06-06 9:00 ` Alice Ryhl
2025-06-11 20:01 ` Boqun Feng
2025-06-12 7:58 ` Benno Lossin
2025-06-12 10:47 ` Danilo Krummrich [this message]
2025-06-12 11:23 ` Alice Ryhl
2025-06-12 8:15 ` Benno Lossin
2025-06-12 10:35 ` Danilo Krummrich
2025-06-12 10:53 ` Benno Lossin
2025-06-12 11:06 ` Danilo Krummrich
2025-06-12 11:15 ` Benno Lossin
2025-06-03 20:48 ` [PATCH 2/3] rust: revocable: indicate whether `data` has been revoked already Danilo Krummrich
2025-06-12 7:59 ` Benno Lossin
2025-06-03 20:48 ` [PATCH 3/3] rust: devres: fix race in Devres::drop() Danilo Krummrich
2025-06-03 23:26 ` Boqun Feng
2025-06-04 9:49 ` Danilo Krummrich
2025-06-12 15:24 ` Boqun Feng
2025-06-12 15:44 ` Danilo Krummrich
2025-06-12 15:48 ` Boqun Feng
2025-06-12 8:13 ` Benno Lossin
2025-06-12 8:15 ` Alice Ryhl
2025-06-12 8:47 ` Benno Lossin
2025-06-12 10:26 ` Danilo Krummrich
2025-06-12 10:59 ` Benno Lossin
2025-06-12 10:31 ` Danilo Krummrich
2025-06-12 11:04 ` Benno Lossin
2025-06-04 12:36 ` [PATCH 0/3] Fix race condition in Devres Miguel Ojeda
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=aEqwQYJdbVSNA7mr@pollux \
--to=dakr@kernel.org \
--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=bsegall@google.com \
--cc=chrisi.schrefl@gmail.com \
--cc=dietmar.eggemann@arm.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=ojeda@kernel.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rostedt@goodmis.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
/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;
as well as URLs for NNTP newsgroup(s).