[RFC PATCH 7/8] rust: add firmware abstractions
FUJITA Tomonori
fujita.tomonori at gmail.com
Tue May 28 10:17:54 UTC 2024
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?
More information about the dri-devel
mailing list