Date:	Thu, 11 Sep 2008 11:52:56 +0200
From:	Frans Pop <elendil@...net.nl>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	davem@...emloft.net, jeffm@...e.com, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	Jeff Garzik <jeff@...zik.org>
Subject: Re: [PATCH] firmware: Allow release-specific firmware dir

On Thursday 11 September 2008, Frans Pop wrote:
> Possible solutions
> ==================
> There are two possible solutions to this.
>
> 1) Move the firmware files to a versioned directory
[...]
> 2) Move the firmware files into a separate package

As mentioned in my previous mail Debian currently uses 2) for its kernel 
packages up to and including 2.6.26. I expect the Debian kernel team to 
also use 2) for 2.6.27, but that's in the future. Debian is currently 
concentrating on 2.6.26 as that's the kernel targeted for the soon-to-be- 
released Lenny release.

>From what I understand from this list (I'm a Debian person and don't 
really follow Ubuntu), Ubuntu seems to have chosen 1).

There are pros and cons to both these solutions and given the different 
philosophies of Debian and Ubuntu those do help explain the different 
choices.

Solution 1:
a) keeps kernel, modules and firmware firmly together
b) ensures there will never be mismatches, even if a firmware file "ABI"
   changes without being properly versioned
c) makes system installation simple: firmware is always just "there"

Solution 2:
a) naturally allows firmware to be split between "free" and "non-free"
b) places a burden on the end-user to install/upgrade the firmware he
   needs separately from the kernel
c) makes system installation more complex as the right additional firmware
   package(s) need to be retrieved and installed
d) will break installed systems on upgrades (unless special measures are
   taken): users may need to install additional firmware packages on a
   kernel upgrade to keep a driver working

Ubuntu has a "things should just work" philosophy. Choosing 1) keeps 
things simple from a user PoV and is a logical choice from that 
perspective.

Debian has strict licencing rules and has never shirked from placing some 
responsibility in the hands of users. Especially 2a) makes 2) the more 
natural choice for Debian.


Note that with 2) you cannot just create one big "linux-firmware" package. 
You will need to package all firmware separately which means that users 
will need to somehow select the specific firmware packages they need for 
their hardware.
The reason for this is the possibility that a driver and its firmware may 
be dropped from the upstream kernel source.

Example
-------
linux-image-2.6.27_1_i386.deb contains:
/boot/vmlinuz-2.6.27
/lib/modules/2.6.27/kernel/net/a.ko
/lib/modules/2.6.27/kernel/net/b.ko

linux-firmware_2.6.27.1_i386.deb contains:
/lib/firmware/a.dat
/lib/firmware/b.dat

For 2.6.28 driver "a" is dropped, which would result in:
linux-image-2.6.28_1_i386.deb contains:
/boot/vmlinuz-2.6.28
/lib/modules/2.6.28/kernel/net/b.ko

linux-firmware_2.6.28.1_i386.deb contains:
/lib/firmware/b.dat

The user installs linux-image-2.6.28 alongside linux-image-2.6.27 and 
upgrades linux-firmware from version 2.6.27.1 to 2.6.28.1.
Oops! The upgrade of the linux-firmware package removed b.dat, which 
effectively means the still installed 2.6.27 kernel is now broken.

To avoid this you need separate packages which can be installed/removed 
independently:
a-firmware_<a-firmware-version>_i386.deb contains:
/lib/firmware/a.dat

b-firmware_<b-firmware-version>_i386.deb contains:
/lib/firmware/b.dat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists