[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aSB1Hcqr6W7EEjjK@google.com>
Date: Fri, 21 Nov 2025 14:20:13 +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
Subject: Re: [PATCH v7 3/6] rust: io: factor common I/O helpers into Io trait
On Wed, Nov 19, 2025 at 01:21:13PM +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>
I said this on a previous version, but I still don't buy the split
into IoFallible and IoInfallible.
For one, we're never going to have a method that can accept any Io - we
will always want to accept either IoInfallible or IoFallible, so the
base Io trait serves no purpose.
For another, the docs explain that the distinction between them is
whether the bounds check is done at compile-time or runtime. That is not
the kind of capability one normally uses different traits to distinguish
between. It makes sense to have additional traits to distinguish
between e.g.:
* Whether IO ops can fail for reasons *other* than bounds checks.
* Whether 64-bit IO ops are possible.
Well ... I guess one could distinguish between whether it's possible to
check bounds at compile-time at all. But if you can check them at
compile-time, it should always be possible to check at runtime too, so
one should be a sub-trait of the other if you want to distinguish
them. (And then a trait name of KnownSizeIo would be more idiomatic.)
And I'm not really convinced that the current compile-time checked
traits are a good idea at all. See:
https://lore.kernel.org/all/DEEEZRYSYSS0.28PPK371D100F@nvidia.com/
If we want to have a compile-time checked trait, then the idiomatic way
to do that in Rust would be to have a new integer type that's guaranteed
to only contain integers <= the size. For example, the Bounded integer
being added elsewhere.
Alice
Powered by blists - more mailing lists