Already posted a list.
The breakage comes from all the existing-at-this-point-today processes
that will not copy the firmware with the module.
We're not talking about one or two people, we are talking about projects
being actively used.
Which in turn means not only those projects need to immediately fix
stuff to make 2.6.27 work, but users who build and test kernels are left
to pick up the pieces when their drivers break too.
It's not theoretical, we have already run into non-working drivers due
to build process changes. And those were the smart guys, the kernel
hackers.
All of the examples I have listed can certainly be fixed -- well, except
the "new kernel, old system" case -- sometimes easily.
* the consequences of the breakage -- 100% non-working driver, possibly
unbootable system
* the likelihood of breakage -- anything that is not a recent version of
a mainstream distro WILL have problems, because it simply does not know
about the firmware that must follow the module whereever it goes.
* the need to immediately add/fix userland and build processes, just to
keep the same driver set working.
* the need for time, to figure out if you are even affected by this change
* the need for time, to plan the best method to implement firmware
deployment in your distro
Without firmware-in-module, it is a basic fact that you are forcing
everyone to fix their stuff, simply to be able to use 2.6.27 like they
did 2.6.26.
That's unfriendly to distros, users, and kernel testers.
Jeff
--
