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: <20170623155123.GB3565@kroah.com>
Date:   Fri, 23 Jun 2017 23:51:23 +0800
From:   Greg KH <gregkh@...uxfoundation.org>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     wagi@...om.org, dwmw2@...radead.org, rafal@...ecki.pl,
        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 Mon, Jun 19, 2017 at 09:35:22PM +0200, Luis R. Rodriguez wrote:
> > I agree, that's what I'm saying here.  I just do not see that happening
> > with your patch set at all.  It's adding more code, a more complex way
> > to interact with the subsystem, and not making driver writer lives any
> > easier at all that I can see.
> 
> There are two things to consider:
> 
> a) The current design of the firmware API, and interfaces with exported symbols
> 
> The case for the driver data API was that we were being super sloppy with extensions,
> to the point was making the internal code base very bug prone and full or redirect
> conditionals with #ifdefery nightmware stuff.
>    
> b) Features of the firmware API
> 
> These have to be evaluated on a case by case basis.

Wait, no, you didn't address my main complaint at all here.  You are
adding complexity for no perceived gain at all with this patch set.

Now you might feel that this series gets you moving forward toward an
end goal of reduced complexity and wonderfulness, but you know how
kernel development works, you have to justify _all_ of your changes, not
just some future end result that is not even presented here.

<wall of text snipped>

I, and others I know, have told you to work on simplifying your
responses, and descriptions, of patches.  Take the extra time to make a
shorter answer.  You will get better results, as I dread having to read
and respond to them currently.

I know you have spent a lot of time and effort on this work, but as it
stands, this crazy new interface (data-driven api vs. the traditional
procedural apis we know and love in Linux), is not acceptable at all.

It's also blocking real bug fixes and features that people want
addressed, which isn't acceptable.

Please take the time to step back, and see if you really want to spend
the effort into creating something that you can easily justify and break
down into acceptable patches.  If so, great, do it, but as it stands
today, that is not what you have done here, at all.

thanks,

greg k-h