On Tue, Nov 29, 2016 at 10:10:56PM +0100, Tom Gundersen wrote: > On Tue, Nov 15, 2016 at 10:28 AM, Johannes Berg > <johan...@sipsolutions.net> wrote: > > My argument basically goes like this: > > > > First, given good drivers (i.e. using request_firmware_nowait()) > > putting firmware even for a built-in driver into initramfs or not > > should be a system integrator decision. If they don't need the device > > that early, it should be possible for them to delay it. Or, perhaps, if > > the firmware is too big, etc. I'm sure we can all come up with more > > examples of why you'd want to do it one way or another. > > This is how I understood the the situation, but I never quite bought > it. What is wrong with the kernel saying "you must put your module and > your firmware together"? Sure, people may want to do things > differently, but what is the real blocker?
0) Firmware upgrades are possible 1) Some firmware is optional 2) Firmware licenses may often not be GPLv2 compatible 3) Some firmwares may be stupid large (remote-proc) as such neither built-in firmware nor using the firmware in initramfs is reasonable. But note that Johannes' main point was that today only a few properly constructed drivers use async fw request, and furthermore given the lack of a deterministic final rootfs signal his proposal was to address the lack of semantics available between kernel and userspcae available for this with a firmware kobject uevent fallback helper. This fallback kobject uevent helper would not reply firmly against files not found until it knows all rootfs firmware paths are ready. > Fundamentally, it seems to me that if a module needs firmware, it > makes no sense to make the module available before the firmware. I'm > probably missing something though :) You are right but just consider all the above. Luis
