Message-ID: <20251124153218.7694b78a.zhiw@nvidia.com>
Date: Mon, 24 Nov 2025 15:32:18 +0200
From: Zhi Wang <zhiw@...dia.com>
To: Alice Ryhl <aliceryhl@...gle.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 Mon, 24 Nov 2025 10:20:41 +0000
Alice Ryhl <aliceryhl@...gle.com> wrote:

> On Mon, Nov 24, 2025 at 12:08:46PM +0200, Zhi Wang wrote:
> > On Fri, 21 Nov 2025 14:20:13 +0000
> > Alice Ryhl <aliceryhl@...gle.com> wrote:
> > 
> > > 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.)
> > > 
> > 
> > Thanks a lot for the detailed feedback. Agree with the points. Let's
> > keep the IoFallible and IoInfallible traits but not just tie them
> > to the bound checks in the docs.
> 
> What do you plan to write in the docs instead?
> 

What I understad according to the discussion:

1. Infallible vs Fallible:

- Infallible indicates the I/O operation can will not return error from
  the API level, and doesn't guarentee the hardware status from device
  level.

- Fallible indicates the I/O operation can return error from the
  API level.

2. compiling-time check vs run-time check:

- driver specifies a known-valid-size I/O region, we go compiling-time
  check (saves the cost of run-time check).

- driver is not able to specifiy a known-valid-size I/O region, we
  should go run-time check.

For IoInfallible, I would write the doc as:

A trait for I/O accessors that are guaranteed to succeed at the API
level.

Implementations of this trait provide I/O operations that do
not return errors to the caller. From the perspective of the I/O
API, the I/O operation is always considered successful.

Note that this does *not* mean that the underlying device is guaranteed
to be in a healthy state. Hardware-specific exceptional states must be
detected and handled by the driver or subsystem managing the device.

For Iofallible, 

A trait for I/O accessors that may return an error.

This trait represents I/O operations where the API can intentionally
return an error. The error typically reflects issues detected by the
subsystem.

> > > 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/

snip

> The last -rc of this cycle is already out, so I don't think you need
> to worry about branch issues - you won't land it in time for that.
> 

I am mostly refering to the dependances if I have to implement this on
top of bounded integer on driver-core-testing.

> 
> But there is another problem: Bounded only supports the case where the
> bound is a power of two, so I don't think it's usable here. You can
> have Io regions whose size is not a power of two.

Any suggestion on this? :) Should I implement something like
BoundedOffset? Also would like to hear some inputs from Danilo as well.

Z.

> 
> Alice

Powered by blists - more mailing lists