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

Frans Pop
2008-07-15T15:57:23Z

Linus Torvalds wrote:
> On Mon, 14 Jul 2008, Jeff Garzik wrote:
>> IMO the newly added /inability/ to build firmware into kernel modules
>> is a clear regression.
>
> IMO you're being stupid.
>
> How about explainign why it makes any difference what-so-ever?
>
> If you can load the module, you can load the firmware. Claiming anything
> else is just _stupid_.

Sure, in theory it's that simple. Here's a concrete example that shows how
things are harder in practice.

I use the 'make deb-pkg' target (from scripts/package) to build my Debian
kernel packages from git. So that needs to be adapted to include
/lib/firmware. No real problem so far.

So then I build 2.6.27-rc1 and install it. Great.

You release 2.6.27-rc2 and I build it. Ouch! It fails to install, at least
if I want to install it _alongside_ 2.6.27-rc1 or other kernels (which I
do!). Why does it fail? Because dpkg's package management does not allow
one package to overwrite files already "owned" by another package.

So, how is this solved by Debian for already existing firmware packages?
Basically by making a separate package for each firmware file (or
driver). This works because there are not too many of them, but having a
huge number of tiny packages is a nightmare by itself.

But anyway, the dep-pkg target will have to be made smarter than it is now
if it's to deal with this [1]. And at least currently it is broken.

If I were able to compile firmware into the modules, the problem would be
solved in one go.

I don't know how the Debian kernel team plans to deal with this for distro
kernel packages. They probably _do_ want to keep them separate [2]. Maybe
by grouping firmware for really common drivers into
firmware-basic-drivers or something along those lines.

Cheers,
FJP

[1] Only quick solution I see is to have it install the firmware in a
versioned directory and have the postinst copy things from there to
/lib/firmware.
[2] As one of the developers for Debian Installer I'm not looking forward
to the complications that is going to cause for us and users.