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

[Henrique de Moraes Holschuh]

On Tue, 15 Jul 2008, Frans Pop wrote:
> 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.

I believe I read in the previous thread that some distros are already using
/lib/firmware/<kernel version>/.

There was also the suggestion of moving the entire set of kernel-packaged
firmware to /lib/modules/<kernel version>/firmware, probably while keeping
/lib/firmware as a second place to look for firmware so that we don't hose
any system.

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

And this thread would have been shorter, even. I hope someone decides to
write that support instead of complaining ;-)

But I do feel we still need a smarter userspace firmware loader to make
firmware packaging less insane.  The "current aproach" you described, with
one firmware per package, is not good.  It doesn't allow for multiple
versions of the firmware to be installed should you need it.

> 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.

I sure hope we go with the more proper fix (a version-enabled firmware
loader that can do the unversioned /lib/firmware as well).  It is far more
resilient in the long run.

> [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.

Yuck.  That would work only if you never needed two active copies of the
kernel [with different firmware files] active at the same time.

> [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.

That was my point.  These firmware loading changes are good, but there is a
lot of crap missing (most of it NOT in the kernel) before it can be exposed
to ordinary users.

And without firmware-in-the-module support (which is the ONLY scenario where
the entire userspace will not notice anything different), this WILL cause
problem to distros, we will need to scramble up and fix it all before we can
package 2.6.26.  I don't know if this is a big problem, though.  The work
will need to be done sooner or later anyway, and we should have enough time
to do so as long as we don't care for packaging the early -rc.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/