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

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

On Mon Sep 15, 2025 at 6:59 AM CEST, Alexandre Courbot wrote:
> 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?

That also lands together with access to initialized fields :) Danilo
already merged it into drm-rust-next: 619db96daf94 ("rust: pin-init: add
pin projections to `#[pin_data]`").

You can only project the entire struct at once, but most of the time
that should be sufficient.

---
Cheers,
Benno