From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C7E67CD5BD1 for ; Mon, 1 Jun 2026 13:24:19 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2D526113345; Mon, 1 Jun 2026 13:24:19 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; secure) header.d=mailbox.org header.i=@mailbox.org header.b="gPF45CLn"; dkim-atps=neutral Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7E2F1113345 for ; Mon, 1 Jun 2026 13:24:17 +0000 (UTC) Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4gTZRx32g1z9t5q; Mon, 1 Jun 2026 15:24:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1780320253; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JS+OPS7x1cO1PMKz8ZECCil0lEgdhEJIwO7HESt43MI=; b=gPF45CLnID21mTvUj8xYxRxQ4VVX63G+B/lBvLd79ubtNLtcW6sG3MBSAarTv0CJdDN4ia zxJh+aMNgCiC9PPihcVEtfE8QTdvHIDxquNne/sF9K+r1knfcjpHjMlCe3PADwg5/8iNb6 2xuLHV35z+m1/IsS/rDoleuarPBUeDC3d9AQaj00AGVosGnwof08MGPHJlP/y5koXJq+PN 4KzwD3KZqzalMOFuS6wfcvZUs9dLqoBCzCpidBaEBstyuBDJwUfKRKHLqBTFqPVml2RTxH fQpc6XSn5xXaKpZ5aIJ85yQDOfuwHvVh0qTCR/H4ts6fnHMOz081InXbqqcjpA== Message-ID: <3829028571be1886b99018040782ef94369b9523.camel@mailbox.org> Subject: Re: [PATCH 3/4] rust: Add dma_fence abstractions From: Philipp Stanner To: Alice Ryhl , phasta@kernel.org Cc: Miguel Ojeda , Boqun Feng , Gary Guo , =?ISO-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Trevor Gross , Danilo Krummrich , Sumit Semwal , Christian =?ISO-8859-1?Q?K=F6nig?= , "Paul E. McKenney" , Frederic Weisbecker , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Uladzislau Rezki , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Daniel Almeida , Greg Kroah-Hartman , Igor Korotin , Lorenzo Stoakes , Alexandre Courbot , FUJITA Tomonori , Krishna Ketan Rai , Shankari Anand , manos@pitsidianak.is, Boris Brezillon , linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, rcu@vger.kernel.org Date: Mon, 01 Jun 2026 15:23:58 +0200 In-Reply-To: References: <20260530143541.229628-2-phasta@kernel.org> <20260530143541.229628-5-phasta@kernel.org> <0ea6b6fdd1e3f1e07445f17c0bf672524938dc85.camel@mailbox.org> <3b216f24afb406b797b8bbb73b3f5c0eec2fdc6c.camel@mailbox.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MBO-RS-ID: 500ef5b9c544510e11b X-MBO-RS-META: rijzzpg3g9rqd1qiwy9fj7s3yrfy4jry X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: phasta@kernel.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, 2026-06-01 at 15:22 +0200, Alice Ryhl wrote: > On Mon, Jun 1, 2026 at 2:47=E2=80=AFPM Philipp Stanner wrote: > >=20 > > 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`] eith= er does not need > > > > > > +/// drop, or lives in a [`RcuBox`]. > > > > > > +pub trait DriverFenceAllowedData: private::Sealed {} > > > > > > + > > > > > > +mod private { > > > > > > +=C2=A0=C2=A0=C2=A0 pub trait Sealed {} > > > > > > +} > > > > > > + > > > > > > +impl DriverFenceAllowedData for F {} > > > > > > +impl DriverFenceAllowedData for RcuBox {} > > > > > > + > > > > > > +impl private::Sealed for F {} > > > > > > +impl private::Sealed for RcuBox {} > > > > >=20 > > > > > Why sealed? Just make the trait unsafe and require the things you > > > > > require from the user. > > > >=20 > > > > This is far better. We definitely only allow the user to pass A or = B, > > > > and only then it compiles. > > >=20 > > > What if I have another type that I want to use here? For example, may= be > > > I have a struct containing a copy field and an RcuBox. Or maybe I hav= e > > > an ARef<_> of some C type that uses rcu for cleanup. Then I must edit > > > this file to add support for it? > > >=20 > > > > The unsafe implementation could be messed up. > > > >=20 > > > > I thought that's what Sealed is for. Or isn't it? > > >=20 > > > 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 hap= py. > > > An unsafe trait can require that sort of requirement from the user. > > >=20 > > > I think what you want is expressed well by `RcuFreeSafe` from this > > > thread: > > > https://rust-for-linux.zulipchat.com/#narrow/channel/291566-Library/t= opic/Consolidate.20.60PollCondVarBox.60.20into.20.60Rcu.2ABox.60/near/59872= 6724 > > >=20 > >=20 > > I guess this is a question of design principles. If you demand an > > RcuBox, you have a guarantee that it's safe. > >=20 > > If you demand an unsafe trait, you open the possibility for people > > messing up. > >=20 > > Due to the unsafe-contract you'd have moved the responsibility for the > > soundness to the driver. > >=20 > > I would not want to block your suggestion, but I am not sure whether > > that's really the better design idea. >=20 > 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. >=20 > Alice