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

[Philipp Stanner <phasta@mailbox.org>]

On Mon, 2026-06-01 at 15:22 +0200, Alice Ryhl wrote:
> On Mon, Jun 1, 2026 at 2:47 PM Philipp Stanner <phasta@mailbox.org> wrote:
> > 
> > On Mon, 2026-06-01 at 12:39 +0000, Alice Ryhl wrote:
> > > On Mon, Jun 01, 2026 at 02:26:17PM +0200, Philipp Stanner wrote:
> > > > On Mon, 2026-06-01 at 10:36 +0000, Alice Ryhl wrote:
> > > > > On Sat, May 30, 2026 at 04:35:11PM +0200, Philipp Stanner wrote:
> > > > > > +/// A trait to enforce that all data in a [`DriverFence`] either does not need
> > > > > > +/// drop, or lives in a [`RcuBox`].
> > > > > > +pub trait DriverFenceAllowedData: private::Sealed {}
> > > > > > +
> > > > > > +mod private {
> > > > > > +    pub trait Sealed {}
> > > > > > +}
> > > > > > +
> > > > > > +impl<F: Copy> DriverFenceAllowedData for F {}
> > > > > > +impl<F: Send> DriverFenceAllowedData for RcuBox<F> {}
> > > > > > +
> > > > > > +impl<F: Copy> private::Sealed for F {}
> > > > > > +impl<F: Send> private::Sealed for RcuBox<F> {}
> > > > > 
> > > > > Why sealed? Just make the trait unsafe and require the things you
> > > > > require from the user.
> > > > 
> > > > This is far better. We definitely only allow the user to pass A or B,
> > > > and only then it compiles.
> > > 
> > > What if I have another type that I want to use here? For example, maybe
> > > I have a struct containing a copy field and an RcuBox. Or maybe I have
> > > an ARef<_> of some C type that uses rcu for cleanup. Then I must edit
> > > this file to add support for it?
> > > 
> > > > The unsafe implementation could be messed up.
> > > > 
> > > > I thought that's what Sealed is for. Or isn't it?
> > > 
> > > Sealed is for making 100% sure that downstream crates/drivers cannot
> > > provide their own implementations. But I don't see why you need that.
> > > All you require is that the value remains valid for one grace period
> > > after cleanup begins. As long as the type satisfies that, you are happy.
> > > An unsafe trait can require that sort of requirement from the user.
> > > 
> > > I think what you want is expressed well by `RcuFreeSafe` from this
> > > thread:
> > > https://rust-for-linux.zulipchat.com/#narrow/channel/291566-Library/topic/Consolidate.20.60PollCondVarBox.60.20into.20.60Rcu.2ABox.60/near/598726724
> > > 
> > 
> > I guess this is a question of design principles. If you demand an
> > RcuBox, you have a guarantee that it's safe.
> > 
> > If you demand an unsafe trait, you open the possibility for people
> > messing up.
> > 
> > Due to the unsafe-contract you'd have moved the responsibility for the
> > soundness to the driver.
> > 
> > I would not want to block your suggestion, but I am not sure whether
> > that's really the better design idea.
> 
> Yes, it's a design principle. You are saying that if someone needs to
> do X but might get it wrong, we should take away the ability to do X?
> I fundamentally disagree with that principle. Unsafe traits is the
> tool Rust created for the exact problem you have; marking places where
> you should be careful is the entire point of 'unsafe'.

I mean, fine by me if the others don't disagree.

But when then do you ever really want a Sealed trait?

P.

> 
> Alice