mbox series

[v3,0/9] rust: workqueue: add bindings for the workqueue

Message ID 20230711093303.1433770-1-aliceryhl@google.com
Headers
Series rust: workqueue: add bindings for the workqueue |

Message

Alice Ryhl July 11, 2023, 9:32 a.m. UTC 
  This patchset contains Rust bindings for the kernel workqueue.

One of the primary goals behind the design used in this patch is that we
must support embedding the `work_struct` as a field in user-provided
types, because this allows you to submit things to the workqueue without
having to allocate, making the submission infallible. If we didn't have
to support this, then the patch would be much simpler. One of the main
things that make it complicated is that we must ensure that the function
pointer in the `work_struct` is compatible with the struct it is
contained within.

The original version of the workqueue bindings was written by Wedson,
but I have rewritten much of it so that it uses the pin-init
infrastructure and can be used with containers other than `Arc`.

Changes v2 -> v3:

 * Moved dependency patches so they are first.
 * Various documentation and comment improvements.
 * Changed implementation of `Arc::from_raw`.
 * Use __INIT_WORK_WITH_KEY instead of __INIT_WORK and use `LockClassKey`
   where appropriate.
 * Removed PhantomPinned from Work. This depends on [1] for correctness.

More detailed changelogs can be found on the individual patches.

v1: https://lore.kernel.org/all/20230517203119.3160435-1-aliceryhl@google.com/
v2: https://lore.kernel.org/all/20230601134946.3887870-1-aliceryhl@google.com/

[1]: https://lore.kernel.org/all/20230630150216.109789-1-benno.lossin@proton.me/

Alice Ryhl (5):
  rust: workqueue: add low-level workqueue bindings
  rust: workqueue: add helper for defining work_struct fields
  rust: workqueue: implement `WorkItemPointer` for pointer types
  rust: workqueue: add `try_spawn` helper method
  rust: workqueue: add examples

Wedson Almeida Filho (4):
  rust: add offset_of! macro
  rust: sync: add `Arc::{from_raw, into_raw}`
  workqueue: introduce `__INIT_WORK_WITH_KEY`
  rust: workqueue: define built-in queues

 include/linux/workqueue.h       |  17 +-
 rust/bindings/bindings_helper.h |   1 +
 rust/helpers.c                  |   8 +
 rust/kernel/lib.rs              |  39 ++
 rust/kernel/sync/arc.rs         |  49 ++-
 rust/kernel/workqueue.rs        | 659 ++++++++++++++++++++++++++++++++
 scripts/Makefile.build          |   2 +-
 7 files changed, 767 insertions(+), 8 deletions(-)
 create mode 100644 rust/kernel/workqueue.rs


base-commit: d2e3115d717197cb2bc020dd1f06b06538474ac3

Comments

Tejun Heo July 11, 2023, 10:17 p.m. UTC | #1 
Hello,

On Tue, Jul 11, 2023 at 09:32:54AM +0000, Alice Ryhl wrote:
> This patchset contains Rust bindings for the kernel workqueue.
> 
> One of the primary goals behind the design used in this patch is that we
> must support embedding the `work_struct` as a field in user-provided
> types, because this allows you to submit things to the workqueue without
> having to allocate, making the submission infallible. If we didn't have
> to support this, then the patch would be much simpler. One of the main
> things that make it complicated is that we must ensure that the function
> pointer in the `work_struct` is compatible with the struct it is
> contained within.
> 
> The original version of the workqueue bindings was written by Wedson,
> but I have rewritten much of it so that it uses the pin-init
> infrastructure and can be used with containers other than `Arc`.

I don't understand a lot but the part that I understand (Alice helped me a
lot, thanks) and the example usages look fine to me. While the interface
leaves some workqueue features uncovered (e.g. flushing, creating custom
workqueues, queueing on a specific CPU), there's nothing blocking adding
them later and this looks like a good place to start. So, from workqueue
POV:

 Acked-by: Tejun Heo <tj@kernel.org>

Please feel free to route the patches through the rust tree. If you want
them to go through the workqueue tree, please let me know.

Thanks.
Miguel Ojeda July 11, 2023, 11:44 p.m. UTC | #2 
On Wed, Jul 12, 2023 at 12:17 AM Tejun Heo <tj@kernel.org> wrote:
>
> I don't understand a lot but the part that I understand (Alice helped me a
> lot, thanks) and the example usages look fine to me. While the interface
> leaves some workqueue features uncovered (e.g. flushing, creating custom
> workqueues, queueing on a specific CPU), there's nothing blocking adding
> them later and this looks like a good place to start. So, from workqueue
> POV:
>
>  Acked-by: Tejun Heo <tj@kernel.org>

Thanks a lot Tejun!

> Please feel free to route the patches through the rust tree. If you want
> them to go through the workqueue tree, please let me know.

As you prefer -- if you are willing to take them and/or maintain or
co-maintain patches to it, and it is not a lot of work for you, then
it would be great to get you involved, of course. Otherwise, we can
apply them to the Rust tree too.

Cheers,
Miguel
Tejun Heo July 12, 2023, 12:27 a.m. UTC | #3 
Hello, Miguel.

On Wed, Jul 12, 2023 at 01:44:47AM +0200, Miguel Ojeda wrote:
> > Please feel free to route the patches through the rust tree. If you want
> > them to go through the workqueue tree, please let me know.
> 
> As you prefer -- if you are willing to take them and/or maintain or
> co-maintain patches to it, and it is not a lot of work for you, then
> it would be great to get you involved, of course. Otherwise, we can
> apply them to the Rust tree too.

It's not a lot of overhead for me but I'm also not sure whether I can be
actually useful. Once folks are happy with it, I can create a separate
branch for this series in the wq tree so that others can easily pull from
it. Let's see how that goes and if my involvement turns out to be pointless
we can route future changes through the rust tree.

Thanks.
Miguel Ojeda July 12, 2023, 4:36 p.m. UTC | #4 
On Wed, Jul 12, 2023 at 2:28 AM Tejun Heo <tj@kernel.org> wrote:
>
> It's not a lot of overhead for me but I'm also not sure whether I can be
> actually useful. Once folks are happy with it, I can create a separate
> branch for this series in the wq tree so that others can easily pull from
> it. Let's see how that goes and if my involvement turns out to be pointless
> we can route future changes through the rust tree.

Sounds good, thanks! (and the branch would indeed be very good, in
case we/someone need it in the Rust tree this cycle too).

Cheers,
Miguel