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@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? 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.
