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 C2E313403E3; Tue, 19 May 2026 13:03:10 +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=1779195790; cv=none; b=Qi+OZ4eyzXwfhvWApI6SFQ/tjpBBrgHdPtqdc2nPXfC3USdAxzE/qerh8WqyanvM3rpDL/qG9TjXthSKoElZLoGnAZfKdIKdqz/Ss1Sy5hgsOIY9Y9AB0dfxKJUqxZsPj4GBV7p5Bz0STv2Rz8oGBvRmXse7GQq06KElAUVTluc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779195790; c=relaxed/simple; bh=+C2REwytvDpqdC7fpylSr1kFZZwJ6+smFl9XkzZoNGk=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:To:From:Subject: References:In-Reply-To; b=O8/oj216J53RCqiB1bq+XruXTQjmAbj4EF9jVe+guUW8MJXRHFdf1pU1yxTJqDrhMQAKLaPqlLxooJF0x6XhW3JCiO/YO8sLST6nOAYdNxgiz5ZPFMC58gfwP6mdxta1ZvN7sqRqSadRKSq4tlfl4optL5qDBVXoQqPHzXFnPJM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZFAci2d8; 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="ZFAci2d8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 38FEEC2BCB3; Tue, 19 May 2026 13:03:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1779195790; bh=+C2REwytvDpqdC7fpylSr1kFZZwJ6+smFl9XkzZoNGk=; h=Date:Cc:To:From:Subject:References:In-Reply-To:From; b=ZFAci2d8oxkEgzfKQypntDGC4/3sOl/EZD/Cif7IJcuE7YJmmxxvopoVOP513Ofvs YqZUHh6U76CV6qrXtkZmNjzwIC+TqPB/8rn1VBqRcmhDD6BuAREpNZhWHyaiV0ntSA EEa2w+3k32v9tDTHdL/35qponLjn3dwNCS+pWF/LekRMX/aktpdkLIlUYU8q3eWATc CTcujhS70SxHn6HZQ6zFOLTQ0QvyyhRJmPj3zyE2XiTzL7nCJ3J4ozxFuJnBCGei8O QUoBU8WAwJ347ud+tCTWDQab54U41ELMrzpY3F1iyjs7+E1rWk4Ni+0+jsd8zjgRj8 EOFP+ednMG2HA== Precedence: bulk X-Mailing-List: rust-for-linux@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: Tue, 19 May 2026 15:03:02 +0200 Message-Id: Cc: "Alexandre Courbot" , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , To: "Gary Guo" From: "Danilo Krummrich" Subject: Re: [PATCH v3 16/27] rust: types: add `ForLt` trait for higher-ranked lifetime support References: <20260517000149.3226762-1-dakr@kernel.org> <20260517000149.3226762-17-dakr@kernel.org> In-Reply-To: On Tue May 19, 2026 at 1:39 PM CEST, Gary Guo wrote: > Danilo, what do you think? Two thoughts about this: (1) The blast radius is bigger than just auxiliary device registrations; = this pattern is applicable to all kinds of registrations that provide the guarantee to be scoped to the bus device being bound. I.e. it is true= for any class device registration, IRQ registration, etc. They should all support HRT eventually; there is a subsequent series where I started = to implement this for DRM. (2) I'm not concerned about the UnsafeForLtImpl approach, as I think for = a human one would really need to be willing to abuse it by intention. I= .e. it is not really different to just using unsafe {} while knowing not = to be able to satisfy the safety requirement. That said, I expect LLMs to be (heavily) used to write drivers, and L= LMs are typically trained to be compliant. So, I could imagine that a pro= mpt along the lines of "Can't we make this work without unsafe somehow?" = leads to an LLM abusing this, while going unnoticed for the user. That said, I think that requiring define_for_lt!() wouldn't be that big of = an issue; the number of registrations per driver is rather limited. Besides that, considering (2) it may actually address a practical concern. If you want to make the change I'm happy to integrate it in a v4, otherwise= a follow-up seems reasonable as well.