linux-kernel - Re: [PATCH v9 1/5] firmware: add extensible driver data params

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: <20170613155041.GB24483@kroah.com>
Date:   Tue, 13 Jun 2017 17:50:41 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     Rafał Miłecki <rafal@...ecki.pl>,
        wagi@...om.org, dwmw2@...radead.org, arend.vanspriel@...adcom.com,
        rjw@...ysocki.net, yi1.li@...ux.intel.com,
        atull@...nsource.altera.com, moritz.fischer@...us.com,
        pmladek@...e.com, johannes.berg@...el.com,
        emmanuel.grumbach@...el.com, luciano.coelho@...el.com,
        kvalo@...eaurora.org, luto@...nel.org,
        torvalds@...ux-foundation.org, keescook@...omium.org,
        takahiro.akashi@...aro.org, dhowells@...hat.com, pjones@...hat.com,
        hdegoede@...hat.com, alan@...ux.intel.com, tytso@....edu,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v9 1/5] firmware: add extensible driver data params

On Tue, Jun 13, 2017 at 05:32:49PM +0200, Luis R. Rodriguez wrote:
> On Tue, Jun 13, 2017 at 03:17:43PM +0200, Greg KH wrote:
> > On Tue, Jun 13, 2017 at 12:31:04PM +0200, Rafał Miłecki wrote:
> > > On 2017-06-13 11:05, Greg KH wrote:
> > > > On Mon, Jun 05, 2017 at 02:39:33PM -0700, Luis R. Rodriguez wrote:
> > > > > As the firmware API evolves we keep extending functions with more
> > > > > arguments.
> > > > > Stop this nonsense by proving an extensible data structure which can
> > > > > be used
> > > > > to represent both user parameters and private internal parameters.
> > > > 
> > > > Let's take a simple C function interface and make it a more complex
> > > > data-driven interface that is impossible to understand and obviously
> > > > understand how it is to be used and works!
> > > > 
> > > > :(
> > > > 
> > > > Seriously, why?  Why are we extending any of this at all?  This series
> > > > adds a ton of new "features" and complexity, but for absolutely no gain.
> > > > 
> > > > Oh, I take it back, you removed 29 lines from the iwlwifi driver.
> > > > 
> > > > That's still not worth it at all, you have yet to sell me on this whole
> > > > complex beast.  I can't see why we need it, and if I, one of the few
> > > > people who thinks they actually understand this kernel interface, can't
> > > > see it, how can you sell it to someone else?
> > > > 
> > > > Sorry, but no, I'm still not going to take this series until you show
> > > > some _REAL_ benefit for it.
> > > 
> > > FWIW I saw (or maybe still see?) a need to extend request_firmware* API to
> > > allow silencing a warning if firmware file is missing.
> > > 
> > > I even sent a trivial patch adding support for this:
> > > [PATCH V4 1/2] firmware: add more flexible request_firmware_async function
> > > https://patchwork.kernel.org/patch/9588787/
> > > (I think it still applies) but it got rejected due to Luis's big rework.
> > 
> > Can you resend this series if it still does apply?
> 
> FWIW just some notes on Rafał's series:
> 
> someone else brought up second that his second no longer should be applied as
> some devices do need what seems to be today's optional request. Also note that
> the approach follows the same I take, just struct a firmware_opts instead of
> driver params... and it does not mesh up the old options as I did in my first
> patch in this series.

As I have no idea what his series looks like at the moment, why not wait
until they are posted again to review them? :)

thanks,

greg k-h