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

From: Frans Pop
Date: Tue Jul 15 2008 - 12:37:56 EST


On Tuesday 15 July 2008, you wrote:
> On Tue, 15 Jul 2008, Frans Pop wrote:
> > 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.
>
> Why don't you just take the kernel-supplied firmware and make it part
> of the kernel package? The same way the kernel-supplied modules are
> part of it?

Important note: this is not me, this is the Debian kernel team based on
Debian Free Software Guidelines (DFSG). If it were purely up to me I'd be
a lot more pragmatic.

1) Because Debian _wants_ them split out for DFSG compliance reasons.
Most of the current firmware packages are kept in the "non-free" section
of the Debian archive while the kernel itself lives in "main".
As long as firmware could not be split out, the compliance problem was the
source of many discussions, but for the most part ignored in practice,
with the exception of a few drivers with really problematic firmware
licences.

2) Because of the overwrite and version management problems.
/lib/firmware as a single dumping ground for firmware for all kernel
versions really sucks from that PoV. One of the huge strengths of Debian
is its ability to clean up after itself when packages are removed.
This is partially solved by giving each firmware file it's own package
because then you can use the versioning of the firmware itself in the
package versions, which allows proper file management by the packaging
system. But as I said, I'm not sure that still works if their number
suddenly explodes.
--
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/