Hi, On Tue, 28 May 2024 08:40:20 +0000 Zhi Wang <zhiw@xxxxxxxxxx> 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@xxxxxxxxxx> 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?
