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]

Date:   Fri, 3 Feb 2017 22:56:36 +0100
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     "Luis R. Rodriguez" <mcgrof@...nel.org>,
        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, Jan 19, 2017 at 10:58:56AM -0800, Bjorn Andersson wrote:
> 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 

I think its important to strive towards this as we get to fix up the old
stuff as much as possible that way. As you could tell from the surge of
fixes on the fallback mechanism it is rather fragile and has not had much
love. With time some of us have been giving it some love, just recently we
added test interfaces for it. We need to address some few more cobwebs before
being 100% certain the precise old interface is the ideal solution for a
fallback mechanism. I haven't personally found any roadblocks from keeping
it compatible on the newer API.

> or will we forever have two
> duplicate systems for loading "firmware" in the kernel?

We need flexibility, that's where the new API comes from, the
old API will remain but new features should go in through the
new API.

> Will the "driver_data" API replace the firmware_class at any point in the future?

The idea is to keep the old API as-is, users requiring new features
would use the newer API. That's all.

  Luis