You cannot compile the firmware into the modules themselves, which is a
regression from current behavior.
Its a problem for cases where you cannot as readily update the kernel
image, such as vendor kernel + driver disk situations, or other examples
already cited.
When the firmware travels with the module, as it does today in tg3, bnx2
and others, is the most reliable system available. The simplest, the
least amount of "parts", the easiest to upgrade, the best method to
guarantee driver/firmware version matches. It works wonderfully today.
Is it difficult to see why someone might want to keep the same attributes?
Compiled-in firmware wastes memory and isn't upgradable -- just like
static kernel vs. kernel modules debate -- but it IS far more reliable
than any system where the firmware is separated from the kernel module
itself.
I'd heartily support David's efforts if it was done in a regression-free
manner. But it is just so easy to build and package a _silently_
non-working driver, simply because the firmware got missed somewhere.
The best path to this new system is to (a) ensure the old system still
works, and then (b) make it easy (transparent?) to adopt the new system.
Jeff
--
