linux-kernel - Re: [PATCH v10 2/5] rust: io: separate generic I/O helpers from MMIO implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aW83HV4lVR5MQlDd@google.com>
Date: Tue, 20 Jan 2026 08:04:45 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: Zhi Wang <zhiw@...dia.com>
Cc: rust-for-linux@...r.kernel.org, linux-pci@...r.kernel.org, 
	linux-kernel@...r.kernel.org, dakr@...nel.org, bhelgaas@...gle.com, 
	kwilczynski@...nel.org, ojeda@...nel.org, alex.gaynor@...il.com, 
	boqun.feng@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com, 
	lossin@...nel.org, a.hindborg@...nel.org, tmgross@...ch.edu, 
	markus.probst@...teo.de, helgaas@...nel.org, cjia@...dia.com, 
	smitra@...dia.com, ankita@...dia.com, aniketa@...dia.com, 
	kwankhede@...dia.com, targupta@...dia.com, acourbot@...dia.com, 
	joelagnelf@...dia.com, jhubbard@...dia.com, zhiwang@...nel.org, 
	daniel.almeida@...labora.com
Subject: Re: [PATCH v10 2/5] rust: io: separate generic I/O helpers from MMIO implementation

On Mon, Jan 19, 2026 at 10:22:44PM +0200, Zhi Wang wrote:
> The previous Io<SIZE> type combined both the generic I/O access helpers
> and MMIO implementation details in a single struct. This coupling prevented
> reusing the I/O helpers for other backends, such as PCI configuration
> space.
> 
> Establish a clean separation between the I/O interface and concrete backends
> by separating generic I/O helpers from MMIO implementation.
> 
> Introduce two traits to handle different access capabilities:
> - IoCapable<T> trait provides infallible I/O operations (read/write)
>   with compile-time bounds checking.
> - IoTryCapable<T> trait provides fallible I/O operations
>   (try_read/try_write) with runtime bounds checking.
> - The Io trait defines convenience accessors (read8/write8, try_read8/
>   try_write8, etc.) that forward to the corresponding IoCapable<T> or
>   IoTryCapable<T> implementations.
> 
> This separation allows backends to selectively implement only the operations
> they support. For example, PCI configuration space can implement IoCapable<T>
> for infallible operations while MMIO regions can implement both IoCapable<T>
> and IoTryCapable<T>.
> 
> Move the MMIO-specific logic into a dedicated Mmio<SIZE> type that
> implements Io and the corresponding `IoCapable<T>` and `IoTryCapable<T>` traits.
> Rename IoRaw to MmioRaw and update consumers to use the new types.
> 
> Cc: Alexandre Courbot <acourbot@...dia.com>
> Cc: Alice Ryhl <aliceryhl@...gle.com>
> Cc: Bjorn Helgaas <helgaas@...nel.org>
> Cc: Gary Guo <gary@...yguo.net>
> Cc: Danilo Krummrich <dakr@...nel.org>
> Cc: John Hubbard <jhubbard@...dia.com>
> Signed-off-by: Zhi Wang <zhiw@...dia.com>

Overall looks good to me. Some comments below:

> +/// Trait representing infallible I/O operations of a certain type.
> +///
> +/// This trait is used to provide compile-time bounds-checked I/O operations.
> +/// Different I/O backends can implement this trait to expose only the operations they support.
> +///
> +/// For example, a PCI configuration space may implement `IoCapable<u8>`, `IoCapable<u16>`,
> +/// and `IoCapable<u32>`, but not `IoCapable<u64>`, while an MMIO region on a 64-bit
> +/// system might implement all four.
> +pub trait IoCapable<T> {
> +    /// Infallible read with compile-time bounds check.
> +    fn read(&self, offset: usize) -> T;
> +
> +    /// Infallible write with compile-time bounds check.
> +    fn write(&self, value: T, offset: usize);
> +}
> +
> +/// Trait representing fallible I/O operations of a certain type.
> +///
> +/// This trait is used to provide runtime bounds-checked I/O operations.
> +/// Backends that do not support fallible operations (e.g., PCI configuration space)
> +/// do not need to implement this trait.
> +pub trait IoTryCapable<T> {
> +    /// Fallible read with runtime bounds check.
> +    fn try_read(&self, offset: usize) -> Result<T>;
> +
> +    /// Fallible write with runtime bounds check.
> +    fn try_write(&self, value: T, offset: usize) -> Result;
> +}

I still think it would make sense to have `IoCapable<T>: IoTryCapable<T>`,
but it's not a big deal.

> +    /// Infallible 64-bit read with compile-time bounds check.
> +    #[cfg(CONFIG_64BIT)]
> +    fn read64(&self, offset: usize) -> u64
> +    #[cfg(CONFIG_64BIT)]
> +    fn try_read64(&self, offset: usize) -> Result<u64>

These don't really need cfg(CONFIG_64BIT). You can place that cfg on
impl blocks of IoCapable<u64>.

e.g., remove above but keep here:

> +// MMIO regions on 64-bit systems also support 64-bit accesses.
> +#[cfg(CONFIG_64BIT)]
> +impl<const SIZE: usize> IoCapable<u64> for Mmio<SIZE> {
> +    define_read!(infallible, read, readq -> u64);
> +    define_write!(infallible, write, writeq <- u64);
> +}

> +#[cfg(CONFIG_64BIT)]
> +impl<const SIZE: usize> IoTryCapable<u64> for Mmio<SIZE> {
> +    define_read!(fallible, try_read, readq -> u64);
> +    define_write!(fallible, try_write, writeq <- u64);
> +}

Alice