Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers.

Jeff Garzik
2008-07-15T20:00:21Z

Linus Torvalds wrote:
>
> On Tue, 15 Jul 2008, Jeff Garzik wrote:
>> Because people should not be forced to fix all their firmware-related breakage
>> immediately, just to boot 2.6.27.
>
> You're continuing to make an argument that doesn't seem to backed up with
> any actual real problems.
>
> Can you point to real breakage? For real people?

Already posted a list.

> It sounds like your whole argument literally boils down to "one or two
> people doing something really stupid or odd cannot just fix their setup".
>
> What is the real-life situation where copying the firmware with the
> modules (but still as separate files) actually breaks?

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.

> IOW, what _is_ this theoretical breakage? And why is it so deadly
> suddenly? Give us real examples that somehow cannot be fixed?

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