From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch [79.135.106.30]) (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 9677D4A11 for ; Sun, 27 Apr 2025 17:11:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.135.106.30 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745773882; cv=none; b=a0SzhMgbgZYOW1LAKVlDE9IohRsPAhRmxbWthpzBoHmUwOP5Z+UIHOG9AVz3IGX7rBEI6move2HcNDUXBQW80zuwMf6BJyxnBF0XUwk7iBogXp9/U4GDen7yIlXIbOEFS3zIQBRPFYnq4N7cNhe54xkBhtlEE7GWGqNKNGRZ2bs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745773882; c=relaxed/simple; bh=ZPGLVu8FvaYMH4Z77PMv1s7904q6EfdpkXZ1p6zVfSc=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=rej2+bheBcQjBa1xK5Hw+T9yFx7Yue8z/Oy/kcb6kNDC7seD7sNZjbqvzfgYhaYoLfM2gyCkY9R/KWI8igkb6vcOcjkl8tbDs0Ei727JY9zB0QfwjO6SSe3jmTKqNOEILNpfJ7QdzZ7mRcy8mjzy6giYtKJmxyEWIKsw5wmq4xg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me; spf=pass smtp.mailfrom=proton.me; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b=G6ioXuuh; arc=none smtp.client-ip=79.135.106.30 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=proton.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b="G6ioXuuh" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1745773878; x=1746033078; bh=0sUVJfqumoE4FsVJpVo0rxr3H29ChmgT8uN7KP0YQmY=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=G6ioXuuhKMPZzzuA8WMSm4BjupksyNKoJTPRcB1I15gFnB2NJB60awB3VqolCnJIi mnyGdlsBF+rd8P75NOywVqpgBKqYY7IfTD6EqlmB1M/4pCCo6Hjao3RXIa/LsjPRrc Pr3kXzowamJ6k7mqcPkMtQ3dkkJ5/KAzXG5NiyeKz+t7v7jPNeArP8IXht24fXrJP4 MUQfp+6yA+OBd9Hu3H4/tyEmobUHPjm/CDFxudcKhVlgpxVb4GhYlxPBtu/DWzFbuv 1NMZHeJO+pMWjP5sZZUhVIg/QVsPOLHQTFT9M7ZUbev162neDyXTEws8ZeWQrYI3Nv gcREqdupVxEiA== Date: Sun, 27 Apr 2025 17:11:12 +0000 To: Danilo Krummrich From: Benno Lossin Cc: gregkh@linuxfoundation.org, rafael@kernel.org, bhelgaas@google.com, kwilczynski@kernel.org, zhiw@nvidia.com, cjia@nvidia.com, jhubbard@nvidia.com, bskeggs@nvidia.com, acurrid@nvidia.com, joelagnelf@nvidia.com, ttabi@nvidia.com, acourbot@nvidia.com, ojeda@kernel.org, alex.gaynor@gmail.com, boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com, a.hindborg@kernel.org, aliceryhl@google.com, tmgross@umich.edu, linux-pci@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] rust: devres: implement Devres::access_with() Message-ID: In-Reply-To: References: Feedback-ID: 71780778:user:proton X-Pm-Message-ID: 70b5f1b0f59e304be70722d2d285d8fa2e95187a Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sun Apr 27, 2025 at 12:10 PM CEST, Danilo Krummrich wrote: > On Sun, Apr 27, 2025 at 08:41:02AM +0000, Benno Lossin wrote: >> On Sat Apr 26, 2025 at 11:24 PM CEST, Danilo Krummrich wrote: >> > On Sat, Apr 26, 2025 at 08:28:30PM +0000, Benno Lossin wrote: >> >> On Sat Apr 26, 2025 at 3:30 PM CEST, Danilo Krummrich wrote: >> >> > + pub fn access_with<'s, 'd: 's>(&'s self, dev: &'d Device) -> Result<&'s T> { >> >>=20 >> >> I don't think that we need the `'d` lifetime here (if not, we should >> >> remove it). >> > >> > If the returned reference out-lives dev it can become invalid, since i= t means >> > that the device could subsequently be unbound. Hence, I think we indee= d need to >> > require that the returned reference cannot out-live dev. >>=20 >> I meant the following signature: >>=20 >> pub fn access_with<'a>(&'a self, dev: &'a Device) -> Result<&= 'a T> >>=20 >> You don't need to specify the additional `'d` one, since lifetimes allow >> subtyping [1]. So if I have a `&'s self` and a `&'d Device` and >> `'d: 's`, then I can supply those arguments to my suggested function and >> the compiler will shorten `'d` to be `'s` or whatever is correct in the >> context. >>=20 >> [1]: https://doc.rust-lang.org/nomicon/subtyping.html#subtyping > > Makes sense, and I don't mind changing it, but I still think the orignal = version > makes the actual requirement more obvious to the reader, i.e. dev must li= ve *at > least* as long as self, but not dev must live *exactly* as long as self. I think it makes the function harder to read, since you have multiple lifetimes around. Once one gets used to the subtyping rule, it's much better to reduce the total amount of lifetimes. Otherwise it seems to me as if it's more complicated. --- Cheers, Benno