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

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Linus Torvalds <torvalds@...>
Cc: <jeff@...>, <arjan@...>, <akpm@...>, <dwmw2@...>, <alan@...>, <linux-kernel@...>
Date: Tuesday, July 15, 2008 - 11:57 am

Linus Torvalds wrote:

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.
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Frans Pop, (Tue Jul 15, 11:57 am)
Prosaic firmware issues, Alexey Dobriyan, (Tue Jul 15, 9:11 pm)
Re: Prosaic firmware issues, Linus Torvalds, (Tue Jul 15, 9:45 pm)
Re: Prosaic firmware issues, David Woodhouse, (Wed Jul 16, 1:54 am)
Re: Prosaic firmware issues, Alexey Dobriyan, (Wed Jul 16, 10:19 am)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Henrique de Moraes Holschuh..., (Tue Jul 15, 2:05 pm)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Arjan van de Ven, (Tue Jul 15, 12:04 pm)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Benjamin Herrenschmidt, (Tue Jul 15, 1:05 am)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Benjamin Herrenschmidt, (Tue Jul 15, 1:15 am)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Arjan van de Ven, (Tue Jul 15, 12:56 am)
Re: [GIT *] Allow request_firmware() to be satisfied , Oliver Neukum, (Tue Jul 15, 2:23 am)
Re: [GIT *] Allow request_firmware() to be satisfied , Oliver Neukum, (Tue Jul 15, 12:52 pm)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Rafael J. Wysocki, (Tue Jul 15, 4:45 pm)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Rafael J. Wysocki, (Wed Jul 16, 5:28 pm)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Rafael J. Wysocki, (Thu Jul 17, 4:42 pm)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Rafael J. Wysocki, (Thu Jul 17, 6:25 pm)
Re: [GIT *] Allow request_firmware() to be satisfied from in..., Rafael J. Wysocki, (Tue Jul 15, 7:45 pm)