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

["Luis R. Rodriguez" <mcgrof@kernel.org>]

On Thu, Aug 11, 2016 at 02:15:31PM -0700, Bjorn Andersson wrote:
> On Thu, Jun 16, 2016 at 4:59 PM, Luis R. Rodriguez <mcgrof@kernel.org> 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?

This is proposed as incremental, the grammar helpers are there to help,
not to force a full sweep change.

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

For starters maintainers would ask developer to extend functionality
via the new descriptor (or whatever we end up calling it).

> > 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"?

We will replace CRDA with an in-kernel API call to fetch the regulatory.bin, it
makes no sense to be referring to regulatory.bin as firmware. There are other
uses already, device configuration, EEPROM default data, etc. In the case to
replace CRDA we will want signature data, and we may want to have some key
specified. To add support for firmware singing we will want to extend yet again
the firmware API with another argument, with the flexible API this will just
be an added entry into the descriptor.

> [..]
> >
> >  - Usermode helpers is completely ignored, *always*
> 
> What technical benefit does this give us?

It means we can compartamentalize the user mode helper. Because...

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

This is the only reason stated so far as why some folks want to use it.
That and some legacy crap (2 drivers). As I have noted elsewhere though
too, this sort of deterministic loading is a generic core fs/exec.c
enhancement for the kernel, not just a firmware thing any more as we
share the same core APIs for reading files now.

> But the direction discussed would
> be unrelated to firmware vs sysdata.

Right, the name chosen for the API is orthogonal. Think of it as two circles,
device data or sysdata and then firmware. The new flexible API just acknowledges
that the first exists and is going to be used, so for instance 802.11 will use it
eventually for regulatory.bin.

  Luis