From: "Luis R. Rodriguez" <mcgrof@xxxxxxxx> This v2 series pushes together a few simple code shifts me and David worked on with a new extensible firmware API. I have bundled these changes together as in my last v1 series [0] it was not clear why the first simple set of changes were being made, and I had sent out the extensible firmware API only as an RFC and separately. I've bundled these two together, this should make it clearer now why we made the first set of changes, the last patch is the meat of the work to consider and review here. Its important to realize that this series does not include firmware signing support. The exact architecture for that is still being discussed -- if we don't all agree on the exact architecture of firmware signing through mailing list discussions one possibility is to just discuss it as one of the topics for the upcoming kernel summit. Now, regardless of the outcome of the exact architecture and design of firmware signing -- a few thing are clear though: 1) we keep extending the firmware API as we come up with more needs, when we do this it means we have a series of unnecessary collateral evolutions on drivers... 2) the user mode helper code needs to die off and although some distributions are now disabling support for it and systemd ripped out support for it, Josh Boyer recently noted that drivers other than dell-rbu now also select FW_LOADER_USER_HELPER_FALLBACK [1]... we should really just compartamentalize such use and phase that out slowly. The extensible firmware API then is being introduced both as a stepping stone to expected changes to the firmware API for Linux firmware signing support and as a way for us to phase out the user mode helper. My original approach to firmware signing was to support firmware signing behind the scenes automatically for all drivers when enabled via Kconfig, with one default key -- similar to how module signing support works. In this original design it was only a side consideration to support custom keys for firmware signing, for instance I had envisioned that we could replace CRDA with a simple firmware request call with our own custom 802.11 key requirements, which would be orthogonal to what distributions decide for "general firmware signing". Upon review though those who have expressed interest in firmware signing have stated interest to be able to specify their own driver key signing criteria from the start. If we end up requiring key requirements to *always* be specified we'll essentially be extending the number of arguments to the firmware API from the start. Instead of having *all* drivers be modified that use the old firmware API, or adding yet another new call, an extensible firmware API would enable only changes to be made for drivers that do want to explicitly opt-in for support for firmware signing, with an added bonus of also avoiding the user mode helper, and enabling this new API to be easily extensible in the future without other collateral evolutions. [0] http://lkml.kernel.org/r/1438725604-22795-1-git-send-email-mcgrof@xxxxxxxxxxxxxxxx [1] http://lkml.kernel.org/r/CA+5PVA6toGj5iboTgK5Casy9vUAQC8SXYWKEx+ojwC51UEV0HA@xxxxxxxxxxxxxx David Howells (2): firmware: fold successful fw read early firmware: generalize reading file contents as a helper Luis R. Rodriguez (3): firmware: generalize "firmware" as "system data" helpers firmware: move completing fw into a helper firmware: add an extensible system data helpers Documentation/firmware_class/system_data.txt | 71 +++++ drivers/base/firmware_class.c | 385 ++++++++++++++++++++++++--- include/linux/sysdata.h | 208 +++++++++++++++ 3 files changed, 627 insertions(+), 37 deletions(-) create mode 100644 Documentation/firmware_class/system_data.txt create mode 100644 include/linux/sysdata.h -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
