public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Alice Ryhl" <aliceryhl@google.com>
Cc: "Zhi Wang" <zhiw@nvidia.com>, <rust-for-linux@vger.kernel.org>,
	<linux-pci@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<bhelgaas@google.com>, <kwilczynski@kernel.org>,
	<ojeda@kernel.org>, <alex.gaynor@gmail.com>,
	<boqun.feng@gmail.com>, <gary@garyguo.net>,
	<bjorn3_gh@protonmail.com>, <lossin@kernel.org>,
	<a.hindborg@kernel.org>, <tmgross@umich.edu>,
	<markus.probst@posteo.de>, <helgaas@kernel.org>,
	<cjia@nvidia.com>, <smitra@nvidia.com>, <ankita@nvidia.com>,
	<aniketa@nvidia.com>, <kwankhede@nvidia.com>,
	<targupta@nvidia.com>, <acourbot@nvidia.com>,
	<joelagnelf@nvidia.com>, <jhubbard@nvidia.com>,
	<zhiwang@kernel.org>, <daniel.almeida@collabora.com>
Subject: Re: [PATCH v9 2/5] rust: io: factor common I/O helpers into Io trait
Date: Fri, 16 Jan 2026 14:23:12 +0100	[thread overview]
Message-ID: <DFQ1O2M9YEDC.3HOIZKNM4HDVF@kernel.org> (raw)
In-Reply-To: <aWoWntMxyhBc9Unx@google.com>

On Fri Jan 16, 2026 at 11:44 AM CET, Alice Ryhl wrote:
> On Thu, Jan 15, 2026 at 11:26:46PM +0200, Zhi Wang wrote:
>> +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.

I think for the PCI configuration space backend we can get away with 3
(which implies that the others have to exist as well).

However - and I think I already mentioned this in previous reply a while ago - I
am not insisting to make this split for this reason, as it is an exception
rather than the rule.

However, note that the only really odd one is 1. All other ones could exist when
there is simply no user for certain accessors, i.e. they would be dead code.

Having that said, I think both have rather minor advantages and disadvantes, so
I'm fine with either. If you feel strongly about this, let's go with your
proposal below.

> 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


  reply	other threads:[~2026-01-16 13:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-15 21:26 [PATCH v9 0/5] rust: pci: add config space read/write support Zhi Wang
2026-01-15 21:26 ` [PATCH v9 1/5] rust: devres: style for imports Zhi Wang
2026-01-15 21:26 ` [PATCH v9 2/5] rust: io: factor common I/O helpers into Io trait Zhi Wang
2026-01-16 10:44   ` Alice Ryhl
2026-01-16 13:23     ` Danilo Krummrich [this message]
2026-01-16 15:23     ` Gary Guo
2026-01-16 15:27       ` Danilo Krummrich
2026-01-17  8:27         ` Zhi Wang
2026-01-16 13:57   ` Markus Probst
2026-01-16 14:44     ` Danilo Krummrich
2026-01-15 21:26 ` [PATCH v9 3/5] rust: io: factor out MMIO read/write macros Zhi Wang
2026-01-15 21:26 ` [PATCH v9 4/5] rust: pci: add config space read/write support Zhi Wang
2026-01-15 21:26 ` [PATCH v9 5/5] sample: rust: pci: add tests for config space routines Zhi Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DFQ1O2M9YEDC.3HOIZKNM4HDVF@kernel.org \
    --to=dakr@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=aniketa@nvidia.com \
    --cc=ankita@nvidia.com \
    --cc=bhelgaas@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=cjia@nvidia.com \
    --cc=daniel.almeida@collabora.com \
    --cc=gary@garyguo.net \
    --cc=helgaas@kernel.org \
    --cc=jhubbard@nvidia.com \
    --cc=joelagnelf@nvidia.com \
    --cc=kwankhede@nvidia.com \
    --cc=kwilczynski@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=markus.probst@posteo.de \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=smitra@nvidia.com \
    --cc=targupta@nvidia.com \
    --cc=tmgross@umich.edu \
    --cc=zhiw@nvidia.com \
    --cc=zhiwang@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox