On Thu Sep 11, 2025 at 3:26 PM CEST, Alexandre Courbot wrote:
> On Thu Sep 11, 2025 at 9:46 PM JST, Danilo Krummrich wrote:
>> On 9/11/25 2:17 PM, Alexandre Courbot wrote:
>>> You can see the whole process on [1]. `libos` is the object that is
>>> returned (although its name and type will change). All the rest it
>>> loading, preparing and running firmware, and that is done on the GPU. I
>>> think it would be very out of place in the GSP module.
>>>
>>> It is also very step-by-step: run this firmware, wait for it to
>>> complete, run another one, wait for a specific message from the GSP, run
>>> the sequencer, etc. And most of this stuff is thrown away once the GSP
>>> is running. That's where the limits of what we can do with `pin_init!`
>>> are reached, and the GSP object doesn't need to be pinned anyway.
>>
>> I don't see that, in the code you linked you have a bunch of calls that don't
>> return anything that needs to survive, this can be in an initializer block.
>>
>> And then you have
>>
>> let mut libos = gsp::GspMemObjects::new(pdev, bar)?;
>>
>> which only needs the device reference and the bar reference.
>>
>> So you can easily write this as:
>>
>> try_pin_init!(Self {
>> _: {
>> // all the throw-away stuff from above
>> },
>> libos <- gsp::GspMemObjects::new(pdev, bar),
>> _: {
>> libos.do_some_stuff_mutable()?;
>> }
>> })
>
> Can the second initializer block access variables created in the first?
No, that's not yet possible :( but I'll make it work next cycle.
---
Cheers,
Benno
