linux-kernel - Re: [PATCH] firmware: remove request_firmware_into

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: <20170712234434.GA21846@wotan.suse.de>
Date:   Thu, 13 Jul 2017 01:44:34 +0200
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Daniel Wagner <wagi@...om.org>,
        David Woodhouse <dwmw2@...radead.org>, rafal@...ecki.pl,
        Arend van Spriel <arend.vanspriel@...adcom.com>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>, yi1.li@...ux.intel.com,
        atull@...nel.org, Moritz Fischer <moritz.fischer@...us.com>,
        pmladek@...e.com, Johannes Berg <johannes.berg@...el.com>,
        emmanuel.grumbach@...el.com, luciano.coelho@...el.com,
        Kalle Valo <kvalo@...eaurora.org>, luto@...nel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        "AKASHI, Takahiro" <takahiro.akashi@...aro.org>,
        David Howells <dhowells@...hat.com>, pjones@...hat.com,
        Hans de Goede <hdegoede@...hat.com>, alan@...ux.intel.com,
        tytso@....edu, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] firmware: remove request_firmware_into_buf()

On Tue, Jun 27, 2017 at 10:37:11AM -0700, Bjorn Andersson wrote:
> On Mon 26 Jun 23:52 PDT 2017, Greg Kroah-Hartman wrote:
> > Why would we keep it if there is no in-tree user for it?  If you want it
> > sometime in the future, great, we can revert the deletion then, but
> > keeping it around for nothing isn't ok, you know that :)
> > 
> 
> Of course I know that :)
> 
> I did put a patch in the tubes for this yesterday [1], it's late for
> v4.13, but I would be happy to see the API stay and we would have a user
> in v4.14 (and tick this off Qualcomm's "required" list).
> 
> [1] https://lkml.org/lkml/2017/6/26/693

Greg,

What have you decided to do?

Also what is the threshold for number of drivers to use a new feature for us to
add it? Note that there is a bundle of features queued up now and as per your
own preference it would seem you want a new API call for each new feature...

Can you clarify that is what you wish for?
Are you *certain* you want to take this approach?

Note that this patch alone was not sufficient to revert all all the stuff for
request_firmware_into_buf(), there was another patch which added the option to
make caching optional, but it was only used internally. Folks already have a
use case for that though *and* existing upstream drivers already have a use
case for that -- the iwlwifi driver is such a case, as they do their own
caching for its driver.

There are similar features in the pipeline which are minor variations to requests
such as optional requests -- do you *really* expect a new API call then to be
created for minor variations of each major call for say optional requests or
requests for without caching?

I had to think about all these things, so now I ask you to also consider this as well.

I ask how many drivers are needed as users for a feature as I think its important
to be fair for the other features in the pipeline which I did start reviewing
and *do* consider sensible to add support for. This was an example feature which
went in with 0 users at all for a while... and now it seems we only have *one*
user still...

  Luis