From: Boqun Feng <boqun.feng@gmail.com>
To: Danilo Krummrich <dakr@kernel.org>
Cc: "Benno Lossin" <lossin@kernel.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Fiona Behrens" <me@kloenk.dev>, "Alban Kurti" <kurti@invicto.ai>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Krzysztof Wilczy´nski" <kwilczynski@kernel.org>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rust: pin-init: add references to previously initialized fields
Date: Sat, 6 Sep 2025 18:57:04 -0700 [thread overview]
Message-ID: <aLzmcK2UM53I2Tbn@tardis-2.local> (raw)
In-Reply-To: <DCLNSNWA7AT7.19OWOXUMJ5ZRJ@kernel.org>
On Sat, Sep 06, 2025 at 12:52:22PM +0200, Danilo Krummrich wrote:
> On Fri Sep 5, 2025 at 7:44 PM CEST, Boqun Feng wrote:
> > On Fri, Sep 05, 2025 at 07:18:25PM +0200, Benno Lossin wrote:
> > [...]
> >> index 606946ff4d7f..1ac0b06fa3b3 100644
> >> --- a/samples/rust/rust_driver_pci.rs
> >> +++ b/samples/rust/rust_driver_pci.rs
> >> @@ -78,8 +78,8 @@ fn probe(pdev: &pci::Device<Core>, info: &Self::IdInfo) -> Result<Pin<KBox<Self>
> >>
> >> let drvdata = KBox::pin_init(
> >> try_pin_init!(Self {
> >> - pdev: pdev.into(),
> >> bar <- pdev.iomap_region_sized::<{ Regs::END }>(0, c_str!("rust_driver_pci")),
> >> + pdev: pdev.into(),
> >
> > Ok, this example is good enough for me to express the concern here: the
> > variable shadowing behavior seems not straightforward (maybe because in
> > normal Rust initalization expression, no binding is created for
> > previous variables, neither do we have a `let` here).
> >
> > Would the future inplace initialization have the similar behavior? I
> > asked because a natural resolution is adding a special syntax like:
> >
> > let a = ..;
> >
> > try_pin_init!(Self {
> > b: a,
> > let a = a.into(); // create the new binding here.
> > c: a, // <- use the previous initalized `a`.
> > }
>
> Can you please clarify the example? I'm a bit confused that this is not a field
> of Self, so currently this can just be written as:
>
Oh, I could have been more clear: `a` is a field of `Self`, and the
`let` part initalizes it.
> try_pin_init!(Self {
> b: a,
> c: a.into,
> })
>
> Of course assuming that a is Clone, as the code above does as well.
>
> So, if we are concerned by the variable shadowing, which I'm less concerned
> about, maybe we can do this:
I'm not that concerned to block this, but it does look to me like we are
inventing a new way (and even a different syntax because normal Rust
initialization doesn't create new bindings) to create binding, so I
think I should bring it up.
>
> // The "original" `a` and `b`.
> let a: A = ...;
> let b: B = ...;
>
> try_pin_init!(Self {
> a, // Initialize the field only.
> let b <- b, // Initialize the field and create a `&B` named `b`.
> c: a.into(), // That's the "original" `a`.
> d <- D::new(b), // Not the original `b`, but the pin-init one.
> })
This looks good to me as well. But I'm curious what the syntax would be
like in the in-place placement language feature in the future.
Regards,
Boqun
next prev parent reply other threads:[~2025-09-07 1:57 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-05 14:00 Benno Lossin
2025-09-05 17:18 ` Benno Lossin
2025-09-05 17:44 ` Boqun Feng
2025-09-06 10:52 ` Danilo Krummrich
2025-09-07 1:57 ` Boqun Feng [this message]
2025-09-07 2:07 ` Boqun Feng
2025-09-07 8:41 ` Benno Lossin
2025-09-07 17:29 ` Danilo Krummrich
2025-09-07 21:06 ` Benno Lossin
2025-09-07 21:39 ` Danilo Krummrich
2025-09-07 22:51 ` Benno Lossin
2025-09-07 23:33 ` Danilo Krummrich
2025-09-08 2:08 ` Boqun Feng
2025-09-08 8:27 ` Benno Lossin
2025-09-08 8:57 ` Danilo Krummrich
2025-09-08 19:38 ` Boqun Feng
2025-09-08 20:31 ` Danilo Krummrich
2025-09-10 10:12 ` Benno Lossin
2025-09-05 17:21 ` Boqun Feng
2025-09-05 18:38 ` Danilo Krummrich
2025-09-06 14:23 ` kernel test robot
2025-09-11 21:35 ` Benno Lossin
2025-12-03 22:05 ` Janne Grunau
2025-12-06 8:23 ` Benno Lossin
2025-12-06 17:02 ` Janne Grunau
2026-01-11 17:06 ` Benno Lossin
2026-02-27 15:02 ` Benno Lossin
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=aLzmcK2UM53I2Tbn@tardis-2.local \
--to=boqun.feng@gmail.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=kurti@invicto.ai \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=me@kloenk.dev \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®