On Wed, Feb 28, 2018 at 06:25:16PM -0800, Josh Triplett wrote: > On Thu, Mar 01, 2018 at 12:38:16AM +0000, Luis R. Rodriguez wrote: > > On Wed, Feb 28, 2018 at 04:00:58PM -0800, Josh Triplett wrote: > > > On Wed, Feb 28, 2018 at 06:26:03PM +0000, Luis R. Rodriguez wrote: > > > > So for folks who enable CONFIG_FW_LOADER=y, they'd now be forced to gain an > > > > extra 13436 bytes broken down as follows: > > > > > > Ah, I see. > > > > > > If you have CONFIG_FW_LOADER and not CONFIG_FW_LOADER_USER_HELPER, then > > > you only have the in-kernel firmware loading mechanism? > > > > Right, we don't have the old fallback mechanism (which BTW used to be > > the default way back in the hayday). > > > > > Given the > > > *substantial* size difference between the two, it seems useful to have > > > that option. > > > > That's what I wanted to get to, is 13436 bytes *substantial* enough to > > merit a kernel configuration option? It seems like that is the case. > > By at least an order of magnitude, yes. OK, then now we have a worthy reasonable description to amend into the kconfig option too. And since its now revisited, I guess we can live with it for a good while. > > > What would it gain to combine the two? > > > > Well Android enables CONFIG_FW_LOADER_USER_HELPER, and if they do, I was trying > > to think if there really was any point in having CONFIG_FW_LOADER_USER_HELPER > > as an option. Who would enable CONFIG_FW_LOADER but not > > CONFIG_FW_LOADER_USER_HELPER? > > An embedded system with a fixed set of hardware that needs exclusively a > fixed set of firmware files known at system build time. Fair enough, this should help also in the description. > > The less hairball of mess of kconfig options the better to test. Even > > though this series has reduced being able to consolidating being > > able to make a kernel now which lets us test all configurations in > > one build. > > > > Who would save some 13436 bytes in the real world? > > *raises hand* Thanks for the feedback. Luis
