Message-Id: <DCSD437J7EES.359ZQ732TXJY@kernel.org>
Date: Sun, 14 Sep 2025 09:58:44 +0200
From: "Benno Lossin" <lossin@...nel.org>
To: "Joel Fernandes" <joelagnelf@...dia.com>, "Danilo Krummrich"
 <dakr@...nel.org>
Cc: "Alexandre Courbot" <acourbot@...dia.com>, "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>, "John Hubbard"
 <jhubbard@...dia.com>, "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 1:02 AM CEST, Joel Fernandes wrote:
> On Sat, Sep 13, 2025 at 09:53:16PM +0200, Danilo Krummrich wrote:
>> On Sat Sep 13, 2025 at 7:13 PM CEST, Joel Fernandes wrote:
>> > On Sat, Sep 13, 2025 at 03:30:31PM +0200, Danilo Krummrich wrote:
>> >> However, we should never do such things. If there's the necessity to do
>> >> something like that, it indicates a design issue.
>> >> 
>> >> In this case, there's no problem, we can use pin-init without any issues right
>> >> away, and should do so.
>> >> 
>> >> pin-init is going to be an essential part of *every* Rust driver given that a
>> >> lot of the C infrastruture that we abstract requires pinned initialization, such
>> >> as locks and other synchronization primitives.
>> >
>> > To be honest, the pinning concept seems like an after thought for such a
>> > fundamental thing that we need, requiring additional macros, and bandaids on
>> > top of the language itself, to make it work for the kernel. I am not alone in
>> > that opinion. This should be first-class in a (systems) language, built into
>> > the language itself? I am talking about the whole pin initialization,
>> > accessing fields dances, etc.
>> 
>> Yes, that's exactly why people (Benno) are already working on making this a
>> language feature (here's a first step in this direction [1]).
>> 
>> Benno should have more details on this.
>> 
>> [1] https://github.com/rust-lang/rust/pull/146307

That's the link to the implementation PR, if you know the internals of
the compiler it sure is useful, but if not, only the first comment is :)

> Ack, thanks for the pointer. I will study it further.

I'd recommend looking at these links, as they talk more about the design
& not the compiler implementation:

* https://github.com/rust-lang/rust/issues/145383
* https://hackmd.io/@rust-lang-team/S1I1aEc_lx
* https://rust-lang.github.io/rust-project-goals/2025h2/field-projections.html

For pin specifically, there also is the pin-ergonomics effort:

* https://github.com/rust-lang/rust/issues/130494

Which is less general than the field projections that I'm working on,
but more specific to pin & tries to make it more compiler internal.

Now for pinned initialization, Alice has a project goal & proposal:

* https://rust-lang.github.io/rust-project-goals/2025h2/in-place-initialization.html
* https://hackmd.io/%40aliceryhl/BJutRcPblx

This proposal was heavily influenced by pin-init & we're actively
working together with others from the Rust community in getting this to
a language feature.

It's a pretty complicated feature and people just worked around it
before, which you can do when starting from the ground-up (similar to
field projections).

>> > Also I am concerned that overusage of pinning defeats a lot of optimizations
>> 
>> pin-init does the oposite it allows us to use a single memory allocation where
>> otherwise you would need multiple.
>> 
>> Can you please show some optimizations that can not be done in drivers due to
>> pin-init for dynamic allocations?
>
> Aren't the vector resizing issues an example? The debugfs discussions for
> example. You can't resize pinned vectors without boxing each element which is
> suboptimal due to requiring additional allocations?

Yes, but that's not really an optimization, is it? In the non-pinned
case, the compiler wouldn't remove the allocation. You can select less
efficient algorithms, since the objects aren't allowed to move, but that
same restriction also applies in C.

---
Cheers,
Benno

Powered by blists - more mailing lists