Messages in this thread | | | Date | Tue, 15 Jul 2008 15:05:35 -0300 | From | Henrique de Moraes Holschuh <> | Subject | Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers. |
| |
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
| |