Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752487AbdF0R0G (ORCPT ); Tue, 27 Jun 2017 13:26:06 -0400 Received: from mx2.suse.de ([195.135.220.15]:58426 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751576AbdF0RZ6 (ORCPT ); Tue, 27 Jun 2017 13:25:58 -0400 Date: Tue, 27 Jun 2017 19:25:54 +0200 From: "Luis R. Rodriguez" To: Vikram Mulukutla Cc: "Luis R. Rodriguez" , Greg KH , Stephen Boyd , Linus Torvalds , Julia Lawall , Daniel Wagner , David Woodhouse , rafal@milecki.pl, Arend Van Spriel , "Rafael J. Wysocki" , "Li, Yi" , atull@opensource.altera.com, Moritz Fischer , Petr Mladek , Johannes Berg , Emmanuel Grumbach , "Coelho, Luciano" , Kalle Valo , Andrew Lutomirski , Jiri Kosina , Kees Cook , "AKASHI, Takahiro" , David Howells , Peter Jones , Hans de Goede , Alan Cox , "Theodore Ts'o" , NeilBrown , Christoph Hellwig , Linux Kernel Mailing List Subject: Re: [PATCH v9 1/5] firmware: add extensible driver data params Message-ID: <20170627172554.GR21846@wotan.suse.de> References: <20170613194011.GI27288@wotan.suse.de> <20170617193815.GI2974@kroah.com> <20170619193522.GH21846@wotan.suse.de> <20170623155123.GB3565@kroah.com> <20170623224338.GX21846@wotan.suse.de> <20170624004828.GA21846@wotan.suse.de> <20170624123951.GA10622@kroah.com> <20170626173328.GC21846@wotan.suse.de> <58a06c12-dbba-8a05-1786-464deec0f090@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58a06c12-dbba-8a05-1786-464deec0f090@codeaurora.org> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3282 Lines: 68 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