From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Gary Guo" <gary@garyguo.net>
Cc: "Gary Guo" <gary@kernel.org>, "Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun@kernel.org>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
rust-for-linux@vger.kernel.org, driver-core@lists.linux.dev,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH 2/8] rust: io: generalize `Mmio` to arbitrary type
Date: Mon, 06 Apr 2026 13:00:06 +0900 [thread overview]
Message-ID: <DHLRSIFTH8NK.1IIMX3HZS47G5@nvidia.com> (raw)
In-Reply-To: <DHLLV6ER6L2T.JF2CXDXSFJX7@garyguo.net>
On Mon Apr 6, 2026 at 8:21 AM JST, Gary Guo wrote:
> On Sun Apr 5, 2026 at 3:55 PM BST, Alexandre Courbot wrote:
>> On Tue Mar 24, 2026 at 12:37 AM JST, Gary Guo wrote:
>>> From: Gary Guo <gary@garyguo.net>
>>>
>>> Currently, `io::Mmio` always represent an untyped region of a compile-time
>>> known minimum size, which is roughly equivalent to `void __iomem*` (but
>>> with bound checks). However, it is useful to also be to represent I/O
>>> memory of a specific type, e.g. `u32 __iomem*` or `struct foo __iomem*`.
>>>
>>> Thus, make `Mmio` generic on arbitrary `T`, where `T` is a sized type, or a
>>> DST that implements `KnownSize`. Similar to the `MmioRaw` change, the
>>> existing behaviour is preserved in the form of `Mmio<Region<SIZE>>`. This
>>> change brings the MMIO closer to the DMA coherent allocation types that we
>>> have, which is already typed.
>>
>> You probably noticed, but the regular `read8`, `read16` remain available
>> irrespective of the `T` parameter, allowing the `Mmio` to be accessed
>> using both the structured type and arbitrary primitives with an offset.
>> I cannot find a reason to label this as unsound, but it might be
>> confusing as it makes projection an additional capability on top of the
>> existing raw I/O methods. This might be worth mentioning in the
>> documentation, or maybe the primitive accessors should only be made
>> available to `Io<Region>`?
>
> Perhaps I could add a new `UntypedIo` trait which is implemented on
> `Region`? And I can restrict these methods to be only usable for it.
>
> I would actually prefer to just remove them, and say you should either access
> via projections, or via register macro.
I am pretty sure there would still be users for more C-like accessors
over an `Region` - although we should discourage their use, removing
them entirely seems a bit drastic to me.
How about an extension trait of `Io` for when `Io::Type` is a region?
This makes the feature unavailable unless the trait is explicitly
imported - just the right level of friction imho.
next prev parent reply other threads:[~2026-04-06 4:00 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <OxgMwl1EcYLh4AqdBa-FaFap0ODNxpID-Hnns6odQVjvPTXqh6VoXM01bZmoVkAOF_5udNfKuCP8YJoW4UE5Fg==@protonmail.internalid>
2026-03-23 15:37 ` [PATCH 0/8] I/O type generalization and projection Gary Guo
2026-03-23 15:37 ` [PATCH 1/8] rust: io: generalize `MmioRaw` to pointer to arbitrary type Gary Guo
2026-03-26 12:53 ` Andreas Hindborg
2026-03-26 14:31 ` Gary Guo
2026-03-23 15:37 ` [PATCH 2/8] rust: io: generalize `Mmio` " Gary Guo
2026-03-26 13:04 ` Andreas Hindborg
2026-03-26 14:32 ` Gary Guo
2026-03-26 18:23 ` Andreas Hindborg
2026-04-02 12:57 ` Gary Guo
2026-04-04 18:57 ` Miguel Ojeda
2026-04-05 14:55 ` Alexandre Courbot
2026-04-05 23:21 ` Gary Guo
2026-04-06 4:00 ` Alexandre Courbot [this message]
2026-03-23 15:37 ` [PATCH 3/8] rust: io: use pointer types instead of address Gary Guo
2026-03-26 14:20 ` Andreas Hindborg
2026-03-26 14:35 ` Gary Guo
2026-03-27 10:11 ` Miguel Ojeda
2026-04-05 14:56 ` Alexandre Courbot
2026-04-05 15:00 ` Danilo Krummrich
2026-04-06 3:49 ` Alexandre Courbot
2026-03-23 15:37 ` [PATCH 4/8] rust: io: add view type Gary Guo
2026-03-26 14:31 ` Andreas Hindborg
2026-04-02 13:01 ` Gary Guo
2026-03-23 15:37 ` [PATCH 5/8] rust: dma: add methods to unsafely create reference from subview Gary Guo
2026-03-26 14:37 ` Andreas Hindborg
2026-03-26 14:44 ` Gary Guo
2026-03-23 15:37 ` [PATCH 6/8] rust: io: add `read_val` and `write_val` function on I/O view Gary Guo
2026-03-27 8:21 ` Andreas Hindborg
2026-03-27 12:19 ` Gary Guo
2026-03-23 15:37 ` [PATCH 7/8] gpu: nova-core: use I/O projection for cleaner encapsulation Gary Guo
2026-03-23 15:38 ` [PATCH 8/8] rust: dma: drop `dma_read!` and `dma_write!` API Gary Guo
2026-03-27 8:25 ` Andreas Hindborg
2026-03-25 11:11 ` [PATCH 0/8] I/O type generalization and projection Andreas Hindborg
2026-03-25 11:19 ` Miguel Ojeda
2026-04-05 15:01 ` Alexandre Courbot
2026-04-05 23:17 ` Gary Guo
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=DHLRSIFTH8NK.1IIMX3HZS47G5@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=aliceryhl@google.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=driver-core@lists.linux.dev \
--cc=gary@garyguo.net \
--cc=gary@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.