linux-kernel - Re: [PATCH v9 2/5] rust: io: factor common I/O helpers into Io trait

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: <aWoWntMxyhBc9Unx@google.com>
Date: Fri, 16 Jan 2026 10:44:46 +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 v9 2/5] rust: io: factor common I/O helpers into Io trait

On Thu, Jan 15, 2026 at 11:26:46PM +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.
> 
> To establish a cleaner layering between the I/O interface and its concrete
> backends, paving the way for supporting additional I/O mechanisms in the
> future, Io<SIZE> need to be factored.
> 
> Factor the common helpers into new {Io, Io64} traits, and move the
> MMIO-specific logic into a dedicated Mmio<SIZE> type implementing that
> trait. Rename the IoRaw to MmioRaw and update the bus MMIO implementations
> to use MmioRaw.
> 
> No functional change intended.
> 
> Cc: Alexandre Courbot <acourbot@...dia.com>
> Cc: Alice Ryhl <aliceryhl@...gle.com>
> Cc: Bjorn Helgaas <helgaas@...nel.org>
> Cc: Danilo Krummrich <dakr@...nel.org>
> Cc: John Hubbard <jhubbard@...dia.com>
> Signed-off-by: Zhi Wang <zhiw@...dia.com>

> +pub trait IoBase {
> +pub trait IoKnownSize: IoBase {
> +pub trait Io: IoBase {
> +pub trait IoKnownSize64: IoKnownSize {
> +pub trait Io64: Io {

The following combinations are possible:

1. IoBase
2. IoBase + Io
3. IoBase + IoKnownSize
4. IoBase + Io + IoKnownSize
5. IoBase + Io + Io64
6. IoBase + Io + Io64 + IoKnownSize
7. IoBase + IoKnownSize + IoKnownSize64
8. IoBase + Io + IoKnownSize + IoKnownSize64
9. IoBase + Io + IoKnownSize + Io64 + IoKnownSize64

I'm not sure all of them make sense. I can't see a scenario where I
would pick 1, 3, 6, 7, or 8.

How about this trait hierachy? I believe I suggested something along
these lines before.

pub trait Io {
pub trait Io64: Io {
pub trait IoKnownSize: Io {

With these traits, these scenarios are possible:

1. Io
2. Io + Io64
3. Io + IoKnownSize
4. Io + Io64 + IoKnownSize

which seems to be the actual set of cases we care about.

Note that IoKnownSize can have methods that only apply when Io64 is
implemented:

trait IoKnownSize: Io {
    /// Infallible 8-bit read with compile-time bounds check.
    fn read8(&self, offset: usize) -> u8;

    /// Infallible 64-bit read with compile-time bounds check.
    fn read64(&self, offset: usize) -> u64
    where
    	Self: Io64;
}

Alice