On Thu Jul 24, 2025 at 11:06 PM CEST, Lyude Paul wrote:
> On Thu, 2025-07-24 at 22:03 +0200, Danilo Krummrich wrote:
>> On Thu Jul 24, 2025 at 9:15 PM CEST, Lyude Paul wrote:
>> > -// SAFETY: All gem objects are refcounted.
>> > -unsafe impl<T: IntoGEMObject> AlwaysRefCounted for T {
>> > - fn inc_ref(&self) {
>> > - // SAFETY: The existence of a shared reference guarantees that
>> > the refcount is non-zero.
>> > - unsafe { bindings::drm_gem_object_get(self.as_raw()) };
>> > - }
>> > -
>> > - unsafe fn dec_ref(obj: NonNull<Self>) {
>> > - // SAFETY: We either hold the only refcount on `obj`, or one of
>> > many - meaning that no one
>> > - // else could possibly hold a mutable reference to `obj` and thus
>> > this immutable reference
>> > - // is safe.
>> > - let obj = unsafe { obj.as_ref() }.as_raw();
>> > -
>> > - // SAFETY:
>> > - // - The safety requirements guarantee that the refcount is
>> > non-zero.
>> > - // - We hold no references to `obj` now, making it safe for us to
>> > potentially deallocate it.
>> > - unsafe { bindings::drm_gem_object_put(obj) };
>> > - }
>> > -}
>>
>> IIUC, you'll add rust/kernel/drm/gem/shmem.rs with a new type shmem::Object
>> that
>> implements IntoGEMObject, right?
>>
>> If this is correct, I think that should work.
>
> Do you mean you think the blanket implementation that we had would work, or
> that getting rid of it would work?
The former.
> Since the blanket implementation we have
> definitely doesn't compile on my machine once we add more then one
> IntoGEMObject impl. (before adding it, it works just fine)
Do you have a branch somewhere, where it doesn't compile?
