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

[Luis R. Rodriguez]

On Mon, Jun 26, 2017 at 07:28:12PM -0700, Vikram Mulukutla wrote:
> On 6/26/2017 10:33 AM, Luis R. Rodriguez wrote:
> > On Sat, Jun 24, 2017 at 02:39:51PM +0200, Greg KH wrote:
> > > Was it used because your version has taken so long to be
> > > submitted/reviwed?
> > 
> > Vikram would have a better idea as he is the one who authored it, but it
> > would seem this effort was in parallel to my own at that time.
> > 
> 
> I must shamefully admit that the story is a bit older - the patch I
> originally worked on was on a v3.4 based tree. 
 
Oh wow so we had *two* separate parallel efforts to simplify this code
somehow...

My earliest sysdata API was based on v4.2-rc5 [0], this was after we decided we
*wanted* to enable to pass more arguments for fw signing from the start, to
enable custom fw criteria, as my original fw signing effort was completely
transparent to the API and matched what we did with module signing [1], and
based on v4.1-rc3.

Only difference is you just worked on the internal data tossed around. I
provided a way to also use this for growing the API.

[0] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=20150805-sysdata
[1] https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=fw-signing-v2-20150513

> We had been forward
> porting it until Stephen Boyd was kind enough (or tired of it) to take
> time out of his clock maintainer-ship and upstream the
> request_firmware_into_buf API. At that point of time it seemed that the
> 'desc' approach was unnecessary, and I agreed.

It was very much needed and it could have helped. Next time please just send
patches right away!

> So Luis's series came
> in much later and wasn't a factor in forward-porting the patches.
>     While it does seem that the _internal_ implementation of
> firmware_class can be a bit friendlier to adding the features that
> are on their way, I can't say the same about the API being exposed to
> drivers in mainline; maintainers and folks with more experience in
> kernel API evolution are better equipped to answer that question.

I actually am not aware how seriously the postulation to the problem I decided
to take on is being considered here...

Some of it may seem straight forward to some based on experience, but due to
the size of the kernel inspired by my prior effort to study collateral
evolutions for both forward and backporting purposes, I've decided to take on
the problem in a bit different light.

Just as your primary reason for your changes was that "the number of things
being passed around between layers of functions inside firmware_class seemed a
bit untenable", I also believed that the way in which we were loosely growing
the firmware API through unnecessary collateral evolutions was untenable.

I will confess that growing the API was just one consideration, another long
term lofty goal also aims towards automatic test driver generation, and enough
is sprinkled on test_driver_data.c that I hope some could infer perhaps how
I started thinking that might be possible one day.

I'm happy to park such effort, so long as we just decide with a path forward so
we can move on and chug on. Perhaps in the future some folks may want to
re-evaluate and consider the approach a bit further.

  Luis