[PATCH 0/6] rust: io: turn IoCapable into a functional trait

Alexandre Courbot posted 6 patches 5 days, 3 hours ago
There is a newer version of this series
rust/kernel/io.rs     | 435 ++++++++++++++++++++++----------------------------
rust/kernel/io/mem.rs |  10 +-
rust/kernel/pci/io.rs |  99 ++++--------
3 files changed, 227 insertions(+), 317 deletions(-)
[PATCH 0/6] rust: io: turn IoCapable into a functional trait
Posted by Alexandre Courbot 5 days, 3 hours ago
`IoCapable<T>` is currently used as a marker trait to signal that the
methods of the `Io` trait corresponding to `T` have been overridden by
the implementor (the default implementations triggering a build-time
error).

This goes against the DRY principle and separates the signaling of the
capability from its implementation, making it possible to forget a step
while implementing a new `Io`.

Another undesirable side-effect is that it makes the implementation of
I/O backends boilerplate-y and convoluted: currently this is done using
two levels of imbricated macros that generate unsafe code.

This patchset fixes these issues by turning `IoCapable` into a
functional trait including the raw implementation of the I/O
accessors for `T` using unsafe methods that work with an arbitrary
address, and making the default methods of `Io` call into these
implementations after checking the bounds.

This makes overriding these accessors on all I/O backends unneeded,
resulting in a net -90 LoCs while avoiding a violation of the DRY
principle and reducing (and simplifying) the use of macros generating
unsafe code.

Patch 1 adds the `io_read` and `io_write` unsafe methods to `IoCapable`,
provides the required implementations for `Mmio` and `pci::ConfigSpace`,
and make the default I/O accessors of `Io` call into them instead of
failing.

Patches 2 to 4 get rid of the `_relaxed` variants we had in `Mmio`,
since these are not usable in code generic against `Io` and makes use of
the macros we want to remove. They are replaced by a `RelaxedMmio`
wrapper type that implements the required `IoCapable`s and is thus
usable in generic code.

Patches 5 and 6 remove the overloaded implementations of the `Io`
methods for `pci::ConfigSpace` and `Mmio`, respectively, while also
deleting the macros that have become unused.

There is more work coming on top of this patchset (notably the
`register!` macro with proper I/O), but I wanted to send this work first
as it stands on its own IMHO and is more digestible from a review
perspective.

The base for this patchset is `driver-core-testing`.

Cc: Zhi Wang <zhiw@nvidia.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Eliot Courtney <ecourtney@nvidia.com>

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
Alexandre Courbot (6):
      rust: io: turn IoCapable into a functional trait
      rust: io: mem: use non-relaxed I/O ops in examples
      rust: io: provide Mmio relaxed ops through a wrapper type
      rust: io: remove legacy relaxed accessors of Mmio
      rust: pci: io: remove overloaded Io methods of ConfigSpace
      rust: io: remove overloaded Io methods of Mmio

 rust/kernel/io.rs     | 435 ++++++++++++++++++++++----------------------------
 rust/kernel/io/mem.rs |  10 +-
 rust/kernel/pci/io.rs |  99 ++++--------
 3 files changed, 227 insertions(+), 317 deletions(-)
---
base-commit: 289b14592cefe95f7d0ef334873c12b96ce3824f
change-id: 20260202-io-81fd368f7565

Best regards,
-- 
Alexandre Courbot <acourbot@nvidia.com>
Re: [PATCH 0/6] rust: io: turn IoCapable into a functional trait
Posted by Alice Ryhl 3 days, 1 hour ago
On Mon, Feb 02, 2026 at 05:12:59PM +0900, Alexandre Courbot wrote:
> `IoCapable<T>` is currently used as a marker trait to signal that the
> methods of the `Io` trait corresponding to `T` have been overridden by
> the implementor (the default implementations triggering a build-time
> error).
> 
> This goes against the DRY principle and separates the signaling of the
> capability from its implementation, making it possible to forget a step
> while implementing a new `Io`.
> 
> Another undesirable side-effect is that it makes the implementation of
> I/O backends boilerplate-y and convoluted: currently this is done using
> two levels of imbricated macros that generate unsafe code.
> 
> This patchset fixes these issues by turning `IoCapable` into a
> functional trait including the raw implementation of the I/O
> accessors for `T` using unsafe methods that work with an arbitrary
> address, and making the default methods of `Io` call into these
> implementations after checking the bounds.
> 
> This makes overriding these accessors on all I/O backends unneeded,
> resulting in a net -90 LoCs while avoiding a violation of the DRY
> principle and reducing (and simplifying) the use of macros generating
> unsafe code.
> 
> Patch 1 adds the `io_read` and `io_write` unsafe methods to `IoCapable`,
> provides the required implementations for `Mmio` and `pci::ConfigSpace`,
> and make the default I/O accessors of `Io` call into them instead of
> failing.
> 
> Patches 2 to 4 get rid of the `_relaxed` variants we had in `Mmio`,
> since these are not usable in code generic against `Io` and makes use of
> the macros we want to remove. They are replaced by a `RelaxedMmio`
> wrapper type that implements the required `IoCapable`s and is thus
> usable in generic code.
> 
> Patches 5 and 6 remove the overloaded implementations of the `Io`
> methods for `pci::ConfigSpace` and `Mmio`, respectively, while also
> deleting the macros that have become unused.
> 
> There is more work coming on top of this patchset (notably the
> `register!` macro with proper I/O), but I wanted to send this work first
> as it stands on its own IMHO and is more digestible from a review
> perspective.
> 
> The base for this patchset is `driver-core-testing`.
> 
> Cc: Zhi Wang <zhiw@nvidia.com>
> Cc: Lyude Paul <lyude@redhat.com>
> Cc: Eliot Courtney <ecourtney@nvidia.com>
> 
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>

Overall looks great!

With the `mmio.relaxed().write(_)` syntax suggested in the thread on
patch 3, this is acked by me.

Acked-by: Alice Ryhl <aliceryhl@google.com>