linux-kernel - Re: [PATCH v4 1/3] firmware: add new extensible firmware API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170119185856.GX10531@minitux>
Date:   Thu, 19 Jan 2017 10:58:56 -0800
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     gregkh@...uxfoundation.org, ming.lei@...onical.com, bp@...en8.de,
        wagi@...om.org, teg@...m.no, mchehab@....samsung.com,
        zajec5@...il.com, linux-kernel@...r.kernel.org,
        markivx@...eaurora.org, stephen.boyd@...aro.org,
        broonie@...nel.org, zohar@...ux.vnet.ibm.com, tiwai@...e.de,
        johannes@...solutions.net, chunkeey@...glemail.com,
        hauke@...ke-m.de, jwboyer@...oraproject.org,
        dmitry.torokhov@...il.com, dwmw2@...radead.org, jslaby@...e.com,
        torvalds@...ux-foundation.org, luto@...capital.net,
        fengguang.wu@...el.com, rpurdie@...ys.net,
        j.anaszewski@...sung.com, Abhay_Salunke@...l.com,
        Julia.Lawall@...6.fr, Gilles.Muller@...6.fr, nicolas.palix@...g.fr,
        dhowells@...hat.com, arend.vanspriel@...adcom.com,
        kvalo@...eaurora.org
Subject: Re: [PATCH v4 1/3] firmware: add new extensible firmware API -
 drvdata

On Thu 12 Jan 07:02 PST 2017, Luis R. Rodriguez wrote:
[..]
> +Fallback mechanisms on the driver data API
> +==========================================
> +
> +The old firmware API provided support for a series of fallback mechanisms. The
> +new driver data API abandons all current notions of the fallback mechanisms,
> +it may soon add support for one though.
> +

What will this fallback mechanism look like? Will it be fully compatible
with the current userspace interfaces or will we forever have two
duplicate systems for loading "firmware" in the kernel?

Will the "sysdata" (or is it named "driver_data"?!) replace the
firmware_class at any point in the future?

Regards,
Bjorn