Re: [PATCH v2 1/8] firmware: add new extensible firmware API - sysdata_file_request*()

[Bjorn Andersson]

On Thu, Jun 16, 2016 at 4:59 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote:
> The firmware API has evolved over the years slowly, as it
> grows we extend it by adding new routines or at times we extend
> existing routines with more or less arguments. This doesn't scale
> well, when new arguments are added to existing routines it means
> we need to traverse the kernel with a slew of collateral
> evolutions to adjust old driver users. The firmware API is also
> now being used for things outside of the scope of what typically
> would be considered "firmware", an example here is the p54 driver
> enables users to provide a custom EEPROM through this interface.
> Another example is optional CPU microcode updates. This list is
> actually quite endless...
>

Why can't this done in an incremental fashion, like other frameworks
has done, by transitioning the existing APIs to take a argument
structure?

How are these cases of "misuse" going to go away with the introduction
of another non-firmware-loading interface?

> There are other subsystems which would like to make use of the
> APIs for similar things (not firmware) but have different
> requirements and criteria which they'd like to be met for the
> requested file. If different requirements are needed it would
> again mean adding more arguments and making a slew of collateral
> evolutions, or adding yet-another-new-API-call.
>

Is the main problem here that it's named "firmware" or that there are
potential requirements that are inconsistent with something loading
"firmware"?

[..]
>
>  - Usermode helpers is completely ignored, *always*

What technical benefit does this give us?


As discussed elsewhere, having a mechanism for postponing firmware
loading until the appropriate file systems are mounted would remove my
dependency on the usermode helper. But the direction discussed would
be unrelated to firmware vs sysdata.

Regards,
Bjorn