Message-Id: <DCT3XP3PVHJZ.2T0L221T3HW5R@nvidia.com>
Date: Mon, 15 Sep 2025 13:59:53 +0900
From: "Alexandre Courbot" <acourbot@...dia.com>
To: "Benno Lossin" <lossin@...nel.org>, "Alexandre Courbot"
 <acourbot@...dia.com>, "Joel Fernandes" <joelagnelf@...dia.com>, "John
 Hubbard" <jhubbard@...dia.com>
Cc: "Miguel Ojeda" <miguel.ojeda.sandonis@...il.com>, "Danilo Krummrich"
 <dakr@...nel.org>, "Miguel Ojeda" <ojeda@...nel.org>, "Alex Gaynor"
 <alex.gaynor@...il.com>, "Boqun Feng" <boqun.feng@...il.com>, "Gary Guo"
 <gary@...yguo.net>, Björn Roy Baron
 <bjorn3_gh@...tonmail.com>, "Andreas Hindborg" <a.hindborg@...nel.org>,
 "Alice Ryhl" <aliceryhl@...gle.com>, "Trevor Gross" <tmgross@...ch.edu>,
 "David Airlie" <airlied@...il.com>, "Simona Vetter" <simona@...ll.ch>,
 "Maarten Lankhorst" <maarten.lankhorst@...ux.intel.com>, "Maxime Ripard"
 <mripard@...nel.org>, "Thomas Zimmermann" <tzimmermann@...e.de>, "Alistair
 Popple" <apopple@...dia.com>, "Timur Tabi" <ttabi@...dia.com>,
 <rust-for-linux@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
 <nouveau@...ts.freedesktop.org>, <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH v5 02/12] gpu: nova-core: move GSP boot code to a
 dedicated method

On Sun Sep 14, 2025 at 11:42 PM JST, Benno Lossin wrote:
> On Sun Sep 14, 2025 at 3:49 AM CEST, Alexandre Courbot wrote:
>> On Sun Sep 14, 2025 at 7:06 AM JST, Joel Fernandes wrote:
>>> On Sat, Sep 13, 2025 at 02:29:54PM -0700, John Hubbard wrote:
>>>> Yes. It's only "paranoia" if the code is bug-free. So Rust itself
>>>> naturally will look "a little" paranoid, that's core to its mission. :)
>>>
>>> This seems to be taken out-of-context, I said "paranoia" mainly because I am
>>> not sure if excessive use of pinning may tend to cause other problems. The
>>> "paranoia" is about over-usage of pinning. Personally, I don't prefer to pin
>>> stuff in my code until I absolutely need to, or when I start having needs for
>>> pinning, like using spinlocks. Maybe I am wrong, but the way I learnt Rust,
>>> data movement is baked into it. I am not yet confident pinning will not
>>> constraint Rust code gen -- but that could just be a part of my learning
>>> journey that I have to convince myself it is Ok to do so in advance of
>>> actually requiring it even if you simply hypothetically anticipate needing it
>>> (as Danilo pointed out that in practice this is not an issue and I do tend to
>>> agree with Miguel and Danilo because they are usually right :-D). I am
>>> researching counter examples :-)
>>
>> You can look at the definition for `Pin` in [1], but it is so short we
>> can paste it here:
>>
>>     #[repr(transparent)]
>>     #[derive(Copy, Clone)]
>>     pub struct Pin<Ptr> {
>>         pointer: Ptr,
>>     }
>>
>> There isn't much getting in the way of optimized code generation - its
>> purpose is simply to constraint the acquisition of mutable references to
>> prevent moving the pointee out.
>>
>> I started this patchset a little bit skeptical about the need to pin so
>> many things, but after seeing the recent additions to `pin_init` and
>> rewriting the code as Danilo suggested, it starteds to click. The
>> supposed restrictions are in practice avoided by embracing the concept
>> fully, and in the end I got that feeling (familiar when writing Rust) of
>> being guided towards the right design - a bit like playing bowling with
>> gutter guards.
>
> That's a great way to put it -- I had a similar experience when writing
> pin-init and thinking about it purely theoretically. Good to see that it
> works out in practice (and continues to do so :).
>
>> Yes, that means redesigning and rebasing our code, but that's also the
>> cost of learning a new language.
>>
>> And yes, things can still be a little bit rough around the edges, but
>> there is awareness and action taken to address these issues, at the
>> compiler level when relevant. This makes me confident for the future.
>
> If you have an issue that you cannot work around, or something that
> looks off, let me know. Maybe that's something that pin-init can deal
> better with or we can have another library that helps with it. After all
> pin-init is specially tailored for the kernel to work :)

I was thinking about the lack of access to already-initialized fields in
the initializer when writing this, which has been covered so thanks for
that. :)

One more thing I still don't know how to do without unsafe code is
accessing structurally-pinned members of a pinned object. I had expected
that projection methods would be generated for such members marked
`#[pin]`, but I haven't found anything yet. For instance, we need to
call mutable methods on a pinned member of a pinned object, and the only
way I have found to do this is to use unsafe code. Is there a better
way?

Powered by blists - more mailing lists