Message-Id: <DEIO1A8N2C66.11BXTCZW4MKWZ@nvidia.com>
Date: Wed, 26 Nov 2025 22:37:34 +0900
From: "Alexandre Courbot" <acourbot@...dia.com>
To: "Alice Ryhl" <aliceryhl@...gle.com>, "Alexandre Courbot"
 <acourbot@...dia.com>
Cc: "Zhi Wang" <zhiw@...dia.com>, <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>, <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 26, 2025 at 6:50 PM JST, Alice Ryhl wrote:
> On Wed, Nov 26, 2025 at 04:52:05PM +0900, Alexandre Courbot wrote:
>> On Tue Nov 25, 2025 at 11:58 PM JST, Alice Ryhl wrote:
>> > On Tue, Nov 25, 2025 at 10:44:29PM +0900, Alexandre Courbot wrote:
>> >> On Fri Nov 21, 2025 at 11:20 PM JST, Alice Ryhl 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.)
>> >> >
>> >> > 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.
>> >> 
>> >> Would that be so different from using an associated const value though?
>> >> IIUC the bounded integer type would play the same role, only slightly
>> >> differently - by that I mean that if the offset is expressed by an
>> >> expression that is not const (such as an indexed access), then the
>> >> bounded integer still needs to rely on `build_assert` to be built.
>> >
>> > I mean something like this:
>> >
>> > trait Io {
>> >     const SIZE: usize;
>> >     fn write(&mut self, i: Bounded<Self::SIZE>);
>> > }
>> 
>> I have experimented a bit with this idea, and unfortunately expressing
>> `Bounded<Self::SIZE>` requires the generic_const_exprs feature and is
>> not doable as of today.
>> 
>> Bounding an integer with an upper/lower bound also proves to be more
>> demanding than the current `Bounded` design. For the `MIN` and `MAX`
>> constants must be of the same type as the wrapped `T` type, which again
>> makes rustc unhappy ("the type of const parameters must not depend on
>> other generic parameters"). A workaround would be to use a macro to
>> define individual types for each integer type we want to support - or to
>> just limit this to `usize`.
>> 
>> But the requirement for generic_const_exprs makes this a non-starter I'm
>> afraid. :/
>
> Can you try this?
>
> trait Io {
>     type IdxInt: Int;
>     fn write(&mut self, i: Self::IdxInt);
> }
>
> then implementers would write:
>
> impl Io for MyIo {
>     type IdxInt = Bounded<17>;
> }
>
> instead of:
> impl Io for MyIo {
>     const SIZE = 17;
> }

The following builds (using the existing `Bounded` type for
demonstration purposes):

    trait Io {
        // Type containing an index guaranteed to be valid for this IO.
        type IdxInt: Into<usize>;

        fn write(&mut self, i: Self::IdxInt);
    }

    struct FooIo;

    impl Io for FooIo {
        type IdxInt = Bounded<usize, 8>;

        fn write(&mut self, i: Self::IdxInt) {
            let idx: usize = i.into();

            // Now do the IO knowing that `idx` is a valid index.
        }
    }

That looks promising, and I like how we can effectively use a wider set
of index types - even, say, a `u16` if a particular I/O happens to have
a guaranteed size of 65536!

I suspect it also changes how we would design the Io interfaces, but I
am not sure how yet. Maybe `IoKnownSize` being built on top of `Io`, and
either unwrapping the result of its fallible methods or using some
`unchecked` accessors?

Powered by blists - more mailing lists