All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Gary Guo" <gary@garyguo.net>
Cc: <gregkh@linuxfoundation.org>, <rafael@kernel.org>,
	<ojeda@kernel.org>, <boqun@kernel.org>,
	<bjorn3_gh@protonmail.com>, <lossin@kernel.org>,
	<a.hindborg@kernel.org>, <aliceryhl@google.com>,
	<tmgross@umich.edu>, <driver-core@lists.linux.dev>,
	<linux-kernel@vger.kernel.org>, <rust-for-linux@vger.kernel.org>
Subject: Re: [PATCH] rust: devres: add 'static bound to Devres<T>
Date: Wed, 27 May 2026 21:49:57 +0200	[thread overview]
Message-ID: <DITPXJNEU74Q.2D56FQAAITBVG@kernel.org> (raw)
In-Reply-To: <DITPEZ9TLM8F.3I808DKPCW4LM@garyguo.net>

On Wed May 27, 2026 at 9:25 PM CEST, Gary Guo wrote:
> On Wed May 27, 2026 at 7:13 PM BST, Danilo Krummrich wrote:
>> On Wed May 27, 2026 at 8:07 PM CEST, Gary Guo wrote:
>>> On Wed May 27, 2026 at 7:04 PM BST, Danilo Krummrich wrote:
>>>> On Wed May 27, 2026 at 4:44 PM CEST, Gary Guo wrote:
>>>>> On Tue May 26, 2026 at 1:04 AM BST, Danilo Krummrich wrote:
>>>>>> Add a 'static bound to prevent storing types with borrowed data in
>>>>>> Devres.
>>>>>
>>>>> The bound should be added on `Devres::new` instead.
>>>>
>>>> I did consider this as it is generally recommended to minimize bounds on
>>>> structs.
>>>>
>>>> However, a Devres<T> with non-'static T is semantically nonsensical, not just
>>>> unconstructible, and I think type level bound represents that better.
>>>
>>> Technically `Devres` can contain references to the registration, which is known
>>> to outlive the bound device.
>>
>> That's technically true, but how would you express "outlives the device" as a
>> lifetime bound on Devres?
>
> Just having the lifetime would mean it outlives the device (lifetimes that
> cannot be guaranteed to outlive the device cannot be used in devres).
>
> In a world with registration data, I would imagine all lifetime parameters on
> registration data are also valid for `Devres`.

[...]

> Resources that depend on both registration data and device resource perhaps?

You'd still need a separate constructor for this, and I'm still not convinced
that this makes a lot of sense.

That said if you feel strongly about it, I don't mind moving the 'static bound
to new() too much.

  reply	other threads:[~2026-05-27 19:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-26  0:04 [PATCH] rust: devres: add 'static bound to Devres<T> Danilo Krummrich
2026-05-26  0:09 ` Danilo Krummrich
2026-05-26  1:08 ` Eliot Courtney
2026-05-26  1:49 ` Alexandre Courbot
2026-05-27 14:44 ` Gary Guo
2026-05-27 18:04   ` Danilo Krummrich
2026-05-27 18:07     ` Gary Guo
2026-05-27 18:13       ` Danilo Krummrich
2026-05-27 19:25         ` Gary Guo
2026-05-27 19:49           ` Danilo Krummrich [this message]
2026-05-28 23:10             ` Danilo Krummrich
2026-05-28 23:10 ` Danilo Krummrich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DITPXJNEU74Q.2D56FQAAITBVG@kernel.org \
    --to=dakr@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=driver-core@lists.linux.dev \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rafael@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.