From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CEDBA199E9D; Sat, 28 Jun 2025 06:06:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751090817; cv=none; b=e2+wV7r/RxzTnnDsz0ckZNpbv/ShX2GYw3r0K+qeQA8+Da8m6qwbFkxTLdOYd4Mg4kHdO6+S/Tik2Cmr8VMgZTyGRjpuc5QkdlildXC1EHCYPJhVVbFMqacNmbwqp9RUQzfFJrdD3YA0niCZ1h94JCY8juWUEcMr8cFEQi4qy1w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751090817; c=relaxed/simple; bh=Buards44X/HUpjs0dh2wtqcXeyk5PePTU+S46Uqp6NU=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=sZC3GG8PalZM32KCAfSMu81R/BfjuNA02QujncypatLAXNtDZokW7HHS/yeAif2dcLbwdWaP7r1cKgnQn+i91vdBtgfjpjF0p+oq249RkkZbwR+TSxaIedJCj+R/7IUA1YIoOyzo4lzorY2o0briYnmx346WyT1d/pPlfpWabTY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fExvWjv8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fExvWjv8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DCBF2C4CEEA; Sat, 28 Jun 2025 06:06:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751090817; bh=Buards44X/HUpjs0dh2wtqcXeyk5PePTU+S46Uqp6NU=; h=Date:Cc:Subject:From:To:References:In-Reply-To:From; b=fExvWjv831PoWwhZph592qqIEKqleCNVIB01Cb3QEQ/wriEWbq/0iy4jPI4cCjAKg t86vbh0nOtl5r5TgIcrqmt634s27/ATTiu010qRSaku1f8BMsRR9vSaCtN5OgNb6X4 Ed4PizLnpXuonzO4J+uz7ZBvHpYrSmR8AnVxUP1931XUY9cBxQyh3ByBmRGiHfcr1q fyslPgMIamGpdWAVVEfsw16e3RKq1AR6NmRBD4p97Z4yM0QXIrzzCPQTUNEZ9R+pS2 EeLYkwEQ1ugUP+IH9TT09Oq/Qz3zyiPuM5OJtF+t72qzaF9tCQlws0WgyCNmclV+Ep /m8y8eYD4h00A== Precedence: bulk X-Mailing-List: linux-pci@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Sat, 28 Jun 2025 08:06:52 +0200 Message-Id: Cc: "Danilo Krummrich" , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v4 5/5] rust: devres: implement register_release() From: "Benno Lossin" To: "Boqun Feng" X-Mailer: aerc 0.20.1 References: <20250626200054.243480-1-dakr@kernel.org> <20250626200054.243480-6-dakr@kernel.org> In-Reply-To: On Sat Jun 28, 2025 at 12:06 AM CEST, Boqun Feng wrote: > On Fri, Jun 27, 2025 at 01:19:53AM +0200, Benno Lossin wrote: >> On Thu Jun 26, 2025 at 10:48 PM CEST, Danilo Krummrich wrote: >> > On Thu, Jun 26, 2025 at 01:37:22PM -0700, Boqun Feng wrote: >> >> On Thu, Jun 26, 2025 at 10:00:43PM +0200, Danilo Krummrich wrote: >> >> > +/// [`Devres`]-releaseable resource. >> >> > +/// >> >> > +/// Register an object implementing this trait with [`register_rel= ease`]. Its `release` >> >> > +/// function will be called once the device is being unbound. >> >> > +pub trait Release { >> >> > + /// The [`ForeignOwnable`] pointer type consumed by [`register= _release`]. >> >> > + type Ptr: ForeignOwnable; >> >> > + >> >> > + /// Called once the [`Device`] given to [`register_release`] i= s unbound. >> >> > + fn release(this: Self::Ptr); >> >> > +} >> >> > + >> >>=20 >> >> I would like to point out the limitation of this design, say you have= a >> >> `Foo` that can ipml `Release`, with this, I think you could only supp= ort >> >> either `Arc` or `KBox`. You cannot support both as the inpu= t >> >> for `register_release()`. Maybe we want: >> >>=20 >> >> pub trait Release { >> >> fn release(this: Ptr); >> >> } >> > >> > Good catch! I think this wasn't possible without ForeignOwnable::Targe= t. >>=20 >> Hmm do we really need that? Normally you either store a type in a shared > > I think it might be quite common, for example, `Foo` may be a general > watchdog for a subsystem, for one driver, there might be multiple > devices that could feed the dog, for another driver, there might be only > one. For the first case we need Arc or the second we can do > Box. I guess then the original `&self` design is better? Not sure... > What's the downside? You'll need to implement `Release` twice: impl Release> for Foo { fn release(this: Box) { /* ... */ } } impl Release> for Foo { fn release(this: Arc) { /* ... */ } } This also means that you can have different behavior for `Box` and `Arc`... --- Cheers, Benno