Messages in this thread | | | Subject | Re: [PATCH v9 1/5] firmware: add extensible driver data params | From | "Li, Yi" <> | Date | Tue, 20 Jun 2017 10:20:43 -0500 |
| |
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
| |