Posted Oct 28, 2012 0:16 UTC (Sun) by iive (guest, #59638)
Parent article: Udev and firmware
This article doesn't actually explain what the problem is. Instead it dances around the issue.
It all starts from the udev serialization.
"Udev ensures full dependency resolution between parent and child events. Parent events have to finish the event handling and have to return, before child event handlers are started. We need to ensure such things so that (among other things) disk events have finished their operations before the partition events are started, so they can rely and access their fully set up parent devices." (Kay Sievers)
The problem is that same principle was applied to firmware. That is, firmware loading was blocked until parent module completes initialization. But this rule does not make sense for the firmware. There is no case where successful loading of firmware when requested would cause any kind of problem. (Hint - cases like "keys locked inside the car" have better solutions.)
Despite that Kay Sievers has refused to acknowledge that the problem is in the udev and insisted that the bugs are in the kernel. So the device developers were forced to start rewriting their drivers in a way that avoids the udev blocking. Mind you, these drivers were written to all requirement of the kernel driver-model, they were working perfectly well, before udev changed the rules. Now they had to introduce asynchronous behavior, so that they can finish a fake initializations early and then do the real one when the firmware is loaded. Since the real initialization is now asynchronous it introduces problem with the initialization of the dependent&sibling modules (that may also do fake and async initialization). There was mentioned even the possibility of designing new core functionality to avoid race conflicts for the now parallel initializations, that used to be serialized. (Think of micro-kernel messaging issues).
In short, it opened a can of worms. Modules were fixed, but that caused regressions for some devices, then new hacks were introduced that repeated the cycle again and again. It made the drivers a lot more complicated and fragile. All this for no real benefit at all.
Of course the intentional blocking of firmware loading by udev is not the only problem when loading firmware. The root of the problems is that userland program have to pipe the firmware into the kernel. This makes loading slow (dependent on scheduler and other factors, udev included). Also it won't work on suspend/resume because kernel modules are resumed before userland.
To solve these issues, asynchronous loading of firmware was introduced. But it didn't solve them, it just made things worse.