Re: [PATCH v4 06/16] rust: drm: restrict AlwaysRefCounted to Normal GEM Object context

["Danilo Krummrich" <dakr@kernel.org>]

On Mon Jun 22, 2026 at 8:25 PM CEST, Lyude Paul wrote:
> On Mon, 2026-06-22 at 20:03 +0200, Danilo Krummrich wrote:
>> One thing I had in mind is that we could have TTM callbacks that guarantee us a
>> Registered DeviceContext that could be represented by the corresonding GEM
>> object. Of course, it could also be represented by a separate
>> &Device<Registered> being passed to the callback.
>
> IMO I think this is better - especially since when I originally introduced
> DeviceContext the intent was that it should be something that we try to omit
> wherever possible, so users mainly only need to interact with it in various
> callbacks that have assumptions about the state of the Device. This makes
> sense logically as well, since the only reason you would need to manually
> specify the DeviceContext a Device is in is when you're running Rust code that
> has been executed from a non-Rust context.
>
> I think for Registration this is definitely ideal, since now that we're trying
> to give it the ability to represent "This device is -currently- registered"
> vs. "This device was registered at some point" trying to avoid generalizing
> types over DeviceContext helps to ensure we don't mistakenly pass through a
> Registered DeviceContext somewhere we didn't mean to. E.g., allowing a user to
> store a gem Object with the Registered device context would technically be a
> leak as it would then be impossible for us to guarantee that all Registered
> devices are presently registered.

In general I agree; and I think I also brought it up a few times that it would
be nice to avoid making GEM objects generic over the DeviceContext.

But now that we already have it (and it is out of the way with this patch
already), I think it could make sense to wait a bit and see how the TTM stuff
turns out before we go back and forth (I think it may be useful there)?

At least I'd prefer to do this in a follow-up patch and, if required, discuss it
there. Do you mind sending a follow-up patch, given that you already looked into
removing it entirely?