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: <6ce1a05b-60ba-7305-abff-405f208399ae@linux.intel.com>
Date:   Tue, 20 Jun 2017 10:20:43 -0500
From:   "Li, Yi" <yi1.li@...ux.intel.com>
To:     AKASHI Takahiro <takahiro.akashi@...aro.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>, wagi@...om.org,
        dwmw2@...radead.org, rafal@...ecki.pl,
        arend.vanspriel@...adcom.com, rjw@...ysocki.net,
        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,
        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 6/19/2017 8:48 PM, AKASHI Takahiro wrote:
> On Mon, Jun 19, 2017 at 05:51:08PM -0500, Li, Yi wrote:
>> Hi Greg,
>>
>> On 6/17/2017 2:38 PM, Greg KH wrote:
>>> On Tue, Jun 13, 2017 at 09:40:11PM +0200, Luis R. Rodriguez wrote:
>>>> On Tue, Jun 13, 2017 at 11:05:48AM +0200, Greg KH wrote:
>>>>> On Mon, Jun 05, 2017 at 02:39:33PM -0700, Luis R. Rodriguez wrote:
>>>
>>>> What you have to ask yourself really is if this makes it *less complex* and
>>>> helps *clean things up* in a much better way than it was before. Also does it
>>>> allow us to *pave the way for new functionality easily*, without creating
>>>> further mess?
>>>
>>> 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.
>>>
>>> Again, the code is now bigger, does more, with not even any real benefit
>>> for existing users.
>>
>> I am still new to the upstreaming world, pardon me if my understanding is
>> naive. :) My take with Luis's driver data API is that it adds a wrapper on
>> top of the old request_firmware APIs, so the new features can be
>> added/disabled by the parameters structures instead of adding/changing API
>> functions. Agree that there is not much new for existing users. It adds more
>> codes (not necessary more complex) but create a consistent way for extension
>> IMO.
> 
> Most of code of my feature, firmware signing, is implemented in common
> place between old and new APIs, while only new API has a parameter,
> DRIVER_DATA_REQ_NO_SIG_CHECK, which allow users to enable/disable
> this feature per-driver-datum. Simple enough.

I meant to say more code does NOT necessary equal to more complex, sorry 
for the confusion.

> 
> So what matters is adding yet another variant of request_firmware_xx()
> vs. adding a mere parameter?

Agree, I also prefer the parameter approach.

> 
> Thanks,
> -Takahiro AKASHI
> 
>> Below are 3 examples I tried to add streaming support to load large firmware
>> files.
>> Adding streaming with driver data API:
>> https://patchwork.kernel.org/patch/9738503 . This patch series depends on
>> non-cache patch series https://patchwork.kernel.org/patch/9793825 , which is
>> bigger than it should be since it added some codes to test firmware caching.
>> and pre-allocate buffer patch series
>> https://patchwork.kernel.org/patch/9738487/
>>
>> By comparison, here is my old streaming RFC with original firmware class:
>> https://lkml.org/lkml/2017/3/9/872
>> Do you think this is the better way?
>>
>> Thanks,
>> Yi