Project

General

Profile

Feature #6559

port NetBSD firmload interface

Added by Hans Rosenfeld almost 4 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Category:
kernel
Start date:
2016-01-16
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

It would be great if we had some sort of DDI firmware loading support to simplify working with elfwrapped firmware modules.

I got inspiration from NetBSD's firmload API and the review comments I got for porting it. Here's what I came up with:
  • firmware modules are elfwrapped kernel modules and should contain one or more firmware images, but nothing else
  • have a skeleton firmware module source file to be used by all firmware modules
  • have a Makefile to be included by all firmware modules' Makefiles that contains all the required logic for running elfwrap and building the firmware module
  • have DDI functions to open/close a firmware module and to extract one firmware image out of a module, using ddi_modopen/ddi_modclose/ddi_modsym

History

#1

Updated by Josef Sipek almost 4 years ago

Do the BSDs elfwrap firmware blobs? I'm worried that elfwraping will make it harder for end users to replace a firmware blob easily. Is there a problem with just keeping the files as-is? It just seems like an extra step (for developers/distros/users) with little to no benefit AFAICS.

What does this skeleton firmware module source file do? Why does it exist? As an example of the firmware API?

#2

Updated by Gordon Ross almost 4 years ago

The elfwrap is easy to apply to a new firmware module.
It's purpose is to make it easy for the kernel module loading framework to load and manage the thing.

I would caution however about putting more than one firmware image in an elfwrap'ed file unless they're always used together. If you were to combine several firmware images, and then need to update one of them, you'll have an increased testing burden because you need to cover all the parts using the other firmware images that updated elfwrap module contains, even though those didn't change.

#3

Updated by Josef Sipek almost 4 years ago

Sure, it's not that difficult to run elfwrap, but running elfwrap + cp is more work than just cp. Not to mention that whoever is doing the update has to know to do it. I'm imagining a user trying to update a firmware blob by grabbing a file from Win/BSD/Linux - none of which do any sort of wrapping to my knowledge. It also prevents the user from comparing (via sha1sum, etc.) an installed module with file from another OS.

Loading a file isn't very hard and it needs to be written only once - for the firmware loading framework. Sure, if every driver had to implement it from scratch then it'd be another story, but that's not the case here.

I just don't see a clear benefit to elfwraping the blobs.

#4

Updated by Hans Rosenfeld over 3 years ago

  • Subject changed from DDI firmware loading interface to port NetBSD firmload interface

It was requested to not use elfwrapped modules. As a consequence I think just porting the NetBSD firmload interface will be sufficient, as that handles plain firmware files.

#5

Updated by Electric Monk almost 3 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

git commit f73e0305a745f17c6a584c4470f99ea1e023657f

commit  f73e0305a745f17c6a584c4470f99ea1e023657f
Author: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>
Date:   2016-11-09T12:33:42.000Z

    6559 port NetBSD firmload interface
    Reviewed by: Gordon Ross <gordon.ross@nexenta.com>
    Reviewed by: Josef 'Jeff' Sipek <josef.sipek@nexenta.com>
    Reviewed by: Robert Mustacchi <rm@joyent.com>
    Approved by: Dan McDonald <danmcd@omniti.com>

Also available in: Atom PDF