On 28/05/2024 13.17, FUJITA Tomonori wrote:> External email: Use caution opening links or attachments
>
>
> Hi,
>
> On Tue, 28 May 2024 08:40:20 +0000
> Zhi Wang <zhiw at nvidia.com> wrote:
>
>> On 27/05/2024 22.18, Danilo Krummrich wrote:
>>> External email: Use caution opening links or attachments
>>>
>>>
>>> On Tue, May 21, 2024 at 08:32:31AM +0300, Zhi Wang wrote:
>>>> On Mon, 20 May 2024 19:24:19 +0200
>>>> Danilo Krummrich <dakr at redhat.com> wrote:
>>>>
>>>>> Add an abstraction around the kernels firmware API to
request firmware
>>>>> images. The abstraction provides functions to access the
firmware
>>>>> buffer and / or copy it to a new buffer allocated with a
given
>>>>> allocator backend.
>>>>>
>>>>
>>>> Was playing with firmware extractions based on this patch.
>>>> Unfortunately I ended up with a lot of pointer operations,
unsafe
>>>> statements.
>>>>
>>>> As we know many vendors have a C headers for the definitions of
the
>>>> firwmare content, the driver extract the data by applying a
struct
>>>> pointer on it.
>>>>
>>>> But in rust, I feel it would nice that we can also have a
common
>>>> firmware extractor for drivers, that can wrap the pointer
operations,
>>>> take a list of the firmware struct members that converted from
C headers
>>>> as the input, offer the driver some common ABI methods to query
them.
>>>> Maybe that would ease the pain a lot.
>>>
>>> So, you mean some abstraction that takes a list of types, offsets
in the
>>> firmware and a reference to the firmware itself and provides
references to the
>>> corresponding objects?
>>>
>>> I agree it might be helpful to have some common infrastructure for
this, but the
>>> operations on it would still be unsafe, since ultimately it
involves
>>> dereferencing pointers.
>>>
>>
>> I think the goal is to 1) concentrate the "unsafe" operations
in a
>> abstraction so the driver doesn't have to write explanation of
unsafe
>> operations here and there, improve the readability of the driver that
>> interacts with vendor-firmware buffer. 2) ease the driver maintenance
>> burden.
>>
>> Some solutions I saw in different projects written in rust for
>> de-referencing a per-defined struct:
>
> Aren't there other abstractions that require that functionality, not
> just the firmware abstractions?
Sure, but they might implement it in a different way due to their
different scale and requirements of maintenance.
I am more interested in what is the better option for firmware
abstractions based on its scale and requirements. 1) how to improve the
readability of the driver, meanwhile keep the operations safe. 2) there
has been C-version vendor-firmware definitions, what would be the best
for the rust driver to leverage it based on the routines that the rust
kernel has already had. 3) how to avoid syncing the headers of vendor
firmware between C and rust version, as the definition can scale up due
to HW generations or ABI changes.
Thanks,
Zhi.