From: "Danilo Krummrich" <dakr@kernel.org>
To: "Alexandre Courbot" <acourbot@nvidia.com>
Cc: "Eliot Courtney" <ecourtney@nvidia.com>,
"Alice Ryhl" <aliceryhl@google.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Abdiel Janulgue" <abdiel.janulgue@gmail.com>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Robin Murphy" <robin.murphy@arm.com>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
lyude@redhat.com, nouveau@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
driver-core@lists.linux.dev, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH 0/9] rust: dma: add CoherentArray for compile-time sized allocations
Date: Sat, 31 Jan 2026 14:56:34 +0100 [thread overview]
Message-ID: <DG2TRSA2LOJ4.3PMICD9ORSB5R@kernel.org> (raw)
In-Reply-To: <DG2SXGUZPEUW.3SYUJHY0GZUWT@nvidia.com>
(Cc: Lyude)
I assume something odd is going on with your mail client for people that have
been added to a thread later on?
On Sat Jan 31, 2026 at 2:16 PM CET, Alexandre Courbot wrote:
> On Sat Jan 31, 2026 at 9:27 PM JST, Danilo Krummrich wrote:
>> We've just generalized I/O to support arbitrary I/O backends (busses, backing
>> storage, etc.).
>>
>> With this we can wire up the I/O traits to DMA and generalize the dma_read() and
>> dma_write() macros accordingly. I.e. we can extend the I/O traits with
>> field_write() and field_read().
>
> With the caveat that the I/O traits for now only support accessing
> primitive types; is the plan to add a function to read any type
> implementing `FromBytes`?
That's exactly what I say above: generalize the dma_read!() and dma_write!()
macros by adding field_write() and field_read() to the I/O traits. :)
For reference, this is where I brought this up originally [1].
[1] https://lore.kernel.org/all/DFOP5BY09539.AFY5L5FV1HNV@kernel.org/
>> (Lyude is going to work on this as a more integrated alternative to iosys_map.
>> It would be good to align with her regarding this work.)
>
> Heads up, I am also doing some plumbing in `io.rs` related to the
> register macro. Maybe we should have a thread on Zulip to discuss what
> everyone is working on.
Done!
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Generic.20I.2FO.20backends/with/571198078
>> This has the advantage that we don't have to duplicate all this infrastructure
>> for I/O memory, DMA, etc.
>>
>> I also think that CoherentSlice is too specific of a type. I'd rather have a
>> generic type, maybe UnsafeSlice or IoSlice, that just uses the I/O backend for
>> accesses.
>
> For me the main appeal of this patchset is that it provides a way to
> work infallibly with a single object or a fixed-size array. I hope
> that's something we can preserve.
Of course, the generic I/O backend infrastructure is based on the distinction
between compile-time and run-time.
WARNING: multiple messages have this Message-ID (diff)
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Alexandre Courbot" <acourbot@nvidia.com>
Cc: "Eliot Courtney" <ecourtney@nvidia.com>,
"Alice Ryhl" <aliceryhl@google.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Abdiel Janulgue" <abdiel.janulgue@gmail.com>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Robin Murphy" <robin.murphy@arm.com>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, driver-core@lists.linux.dev,
rust-for-linux@vger.kernel.org
Subject: Re: [PATCH 0/9] rust: dma: add CoherentArray for compile-time sized allocations
Date: Sat, 31 Jan 2026 14:56:34 +0100 [thread overview]
Message-ID: <DG2TRSA2LOJ4.3PMICD9ORSB5R@kernel.org> (raw)
In-Reply-To: <DG2SXGUZPEUW.3SYUJHY0GZUWT@nvidia.com>
(Cc: Lyude)
I assume something odd is going on with your mail client for people that have
been added to a thread later on?
On Sat Jan 31, 2026 at 2:16 PM CET, Alexandre Courbot wrote:
> On Sat Jan 31, 2026 at 9:27 PM JST, Danilo Krummrich wrote:
>> We've just generalized I/O to support arbitrary I/O backends (busses, backing
>> storage, etc.).
>>
>> With this we can wire up the I/O traits to DMA and generalize the dma_read() and
>> dma_write() macros accordingly. I.e. we can extend the I/O traits with
>> field_write() and field_read().
>
> With the caveat that the I/O traits for now only support accessing
> primitive types; is the plan to add a function to read any type
> implementing `FromBytes`?
That's exactly what I say above: generalize the dma_read!() and dma_write!()
macros by adding field_write() and field_read() to the I/O traits. :)
For reference, this is where I brought this up originally [1].
[1] https://lore.kernel.org/all/DFOP5BY09539.AFY5L5FV1HNV@kernel.org/
>> (Lyude is going to work on this as a more integrated alternative to iosys_map.
>> It would be good to align with her regarding this work.)
>
> Heads up, I am also doing some plumbing in `io.rs` related to the
> register macro. Maybe we should have a thread on Zulip to discuss what
> everyone is working on.
Done!
Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/Generic.20I.2FO.20backends/with/571198078
>> This has the advantage that we don't have to duplicate all this infrastructure
>> for I/O memory, DMA, etc.
>>
>> I also think that CoherentSlice is too specific of a type. I'd rather have a
>> generic type, maybe UnsafeSlice or IoSlice, that just uses the I/O backend for
>> accesses.
>
> For me the main appeal of this patchset is that it provides a way to
> work infallibly with a single object or a fixed-size array. I hope
> that's something we can preserve.
Of course, the generic I/O backend infrastructure is based on the distinction
between compile-time and run-time.
next prev parent reply other threads:[~2026-01-31 13:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-30 8:34 [PATCH 0/9] rust: dma: add CoherentArray for compile-time sized allocations Eliot Courtney
2026-01-30 8:34 ` [PATCH 1/9] rust: dma: rename CoherentAllocation fallible methods Eliot Courtney
2026-01-30 8:34 ` [PATCH 2/9] rust: dma: parameterize CoherentAllocation with AllocationSize Eliot Courtney
2026-01-30 8:34 ` [PATCH 3/9] rust: dma: add CoherentArray for compile-time sized allocations Eliot Courtney
2026-01-30 8:34 ` [PATCH 4/9] rust: dma: simplify try_dma_read! and try_dma_write! Eliot Courtney
2026-01-30 8:34 ` [PATCH 5/9] rust: dma: rename try_item_from_index to try_ptr_at Eliot Courtney
2026-01-30 8:34 ` [PATCH 6/9] rust: dma: add dma_read! and dma_write! macros Eliot Courtney
2026-01-30 10:26 ` Alice Ryhl
2026-01-30 10:26 ` Alice Ryhl
2026-01-30 8:34 ` [PATCH 7/9] rust: dma: implement decay from CoherentArray to CoherentSlice Eliot Courtney
2026-01-30 8:34 ` [PATCH 8/9] rust: dma: add CoherentObject for single element allocations Eliot Courtney
2026-01-30 8:34 ` [PATCH 9/9] gpu: nova-core: migrate to CoherentArray and CoherentObject Eliot Courtney
2026-01-31 12:27 ` [PATCH 0/9] rust: dma: add CoherentArray for compile-time sized allocations Danilo Krummrich
2026-01-31 12:27 ` Danilo Krummrich
2026-01-31 13:16 ` Alexandre Courbot
2026-01-31 13:56 ` Danilo Krummrich [this message]
2026-01-31 13:56 ` Danilo Krummrich
2026-02-02 14:22 ` Gary Guo
2026-02-02 14:22 ` 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=DG2TRSA2LOJ4.3PMICD9ORSB5R@kernel.org \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=abdiel.janulgue@gmail.com \
--cc=acourbot@nvidia.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=driver-core@lists.linux.dev \
--cc=ecourtney@nvidia.com \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=lyude@redhat.com \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=robin.murphy@arm.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--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.