Re: [PATCH 3/4] rust: Add dma_fence abstractions

[Daniel Almeida <dwlsalmeida@gmail.com>]

>> 
>>> 
>>> So, by passing self by value to the ::callback(), you're basically
>>> telling users "hey, BTW, don't forget to defer the drop to some
>>> workqueue if you think it's not atomic-safe". And how can users know
>>> that the thing they're about to drop can be dropped in atomic context?
>>> They basically have to audit the ::drop() of all the resources they
>>> embed in their type implementing FenceCb. Not only that, but they also
>>> have to design the thing so the deferral of this ::drop() doesn't
>>> allocate, because, obviously, allocating in atomic context is
>>> tricky/fallible. AFAIK, none of this can be spot at compile-time (I
>>> remember Gary/Danilo mentioning that we could teach the klint about
>>> some of these rules). This would leave us with runtime checks like
>>> might_sleep(), but most of the C putters (xxx_put(object)) don't have
>>> might_sleep() in the path where the decref doesn't lead to a refcnt=0
>>> situation.
>>> 
>>> TLDR; Call this PTSD if you want, but this is the sort of bugs I
>>> struggled with on the C side, and I can predict that the exact same
>>> will happen in rust drivers if we expose the FenceCb as it is designed
>>> here and we don't have a way to check the soundness of the FenceCb
>>> implementations at compile time.
>> 
>> My guess would be that the existence of unsafe-traits is the admission
>> of Rust that this just cannot be guaranteed by design.
>> 
>> If a driver cannot know whether this or that is safe to drop, then it
>> would have to defer it's dropping. Or would there be cases where this
>> also doesn't work?
> 
> 
> Although I totally understand where Boris is coming from here, and I agree with
> him, the reality is that the current &mut self design doesn’t solve this. An
> unsafe trait could work as a pinky-promise by drivers, which is half-way there.
> 
> What we ideally would like to have is a bound though, something like:
> 
> T: !Drop
> 
> If I recall correctly there were people working to get support for that on
> Rust? I think there are two things here: !Trait, which is not supported except
> for !Sized IIRC, and having an auto trait that represents types that implement
> Drop, similar to Send and Sync.
> 


In fact, ping the pin-init people here, i.e.: Benno, Gary, etc. 

What is the magic behind “MustNotImplDrop”? Perhaps we could apply that here?

— Daniel