Re: [PATCH v5 02/12] gpu: nova-core: move GSP boot code to a dedicated method

["Benno Lossin" <lossin@kernel.org>]

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