[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <eca9693146dd9db88a6ea0b8b435d2ef0246ee2e.camel@mailbox.org>
Date: Mon, 09 Feb 2026 09:21:51 +0100
From: Philipp Stanner <phasta@...lbox.org>
To: Boris Brezillon <boris.brezillon@...labora.com>
Cc: phasta@...nel.org, Gary Guo <gary@...yguo.net>, David Airlie
<airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Danilo Krummrich
<dakr@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, Benno Lossin
<lossin@...nel.org>, Christian König
<christian.koenig@....com>, Daniel Almeida <daniel.almeida@...labora.com>,
Joel Fernandes <joelagnelf@...dia.com>, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org, rust-for-linux@...r.kernel.org
Subject: Re: [RFC PATCH 2/4] rust: sync: Add dma_fence abstractions
On Fri, 2026-02-06 at 12:04 +0100, Boris Brezillon wrote:
> On Fri, 06 Feb 2026 10:32:38 +0100
> Philipp Stanner <phasta@...lbox.org> wrote:
>
[…]
> >
> > So I strongly think that we'd either want to drop data: T, or we should
> > think about possibilities to hide it from other drivers.
> >
> > I've got currently no idea how that could be addressed in Rust, though
>
> So, as Danilo explained in his reply, there's two kind of users:
>
> 1. those that want to wait on fences (that'd be the JobQueue, for
> instance)
> 2. those that are emitting fences (AKA those implementing the fence_ops
> in C)
>
> And each of them should be given different access to the underlying
> dma_fence, hence the proposal to have different objects to back
> those concepts.
That makes sense and can be implemented. I can pick it up.
P.
Powered by blists - more mailing lists