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 is*substantial* enough to > merit a kernel configuration option? It seems like that is the case. By at least an order of magnitude, yes. > > 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. > 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*
