|| ||David Woodhouse <dwmw2-AT-infradead.org>|
|| ||Arjan van de Ven <arjan-AT-linux.intel.com>|
|| ||Re: [Ksummit-2008-discuss] RFC: Moving firmware blobs out of the
|| ||Fri, 30 May 2008 02:04:18 +0300|
|| ||David Miller <davem-AT-davemloft.net>,
On Thu, 2008-05-29 at 14:11 -0700, Arjan van de Ven wrote:
> David Miller wrote:
> > Arjan, by definition the firmware has to be tied to the kernel somehow.
> > THe datastructure and other aspects are often tied directly to
> > the firmware version loaded.
> agreed that there are cases like this, and I have no personal objection to having
> those in the kernel.
> > If debian or whoever else have these concernes and want to rip the
> > firmware out, it is one hundred percent their problem to patch things
> > out of the kernel tree they use.
> I don't care at all about the argument from that camp.
I do -- partly because it's not just from the fundamentalist camp,
partly because (after the work I've been doing) it doesn't actually
_hurt_ us to assume that they're right, but mostly because I have a
horrible suspicion that they _are_ right.
Expanding on those three points not in that order...:
The firmware is an independent and separate work in itself. Section 2 of
the GPL talks about such sections of the work, explicitly. The only way
to excuse what we're doing at the moment is to call it 'mere
aggregation' -- an exception which was intended to handle stuff like the
'freeware' CDs on the covers of magazines, distributing a bunch of
unrelated software. Not a coherent work combining software from
different sources into a single entity which works closely together as
one, and where one part is useless without the other.
The more that people claim it would be such a burden to split the
firmware from their driver because they're so closely interrelated, the
more they are arguing against the 'mere aggregation' defence, which was
tenuous enough in the first place.
And it isn't just the nutters. Fedora also wants to ship the firmware in
a separate package from the kernel -- since the alleged GPL violation is
such a _gratuitous_ risk given that we always use an initrd anyway, and
because people want to be able to do 'Free' spins which don't feature
the firmware at all, even in the source packages.
I strongly suspect we'd end up building the Fedora kernel from a special
'linux-2.6.2x-nofirmware.tar.bz2' tarball, rather than using the stock
tarballs if they continue to include the firmware. We do similar things
with 'openssh-5.0p1-noacss.tar.bz2' already, for example.
> My aim was more the opposite: be able to get MORE firmware easily used/loaded,
> not less. Right now it's a royal pain for users to get all the right pieces of
> firmware.... having ONE place to put all that would go a long way of making that
> side of things easier.
There are people who own copyright on firmware who refuse to put it into
the Linux source tree, because their lawyers don't believe the 'mere
aggregation' line, and believe that including it in the kernel source in
any form would require them to license it under the GPL.
But those same companies _would_ consider putting their firmware into a
non-GPL'd 'linux-firmware' repository instead. So by moving our firmware
out into a separate tree, we should actually make it _easier_ for people
to find all the necessary firmware in one place.
It's not as if it's hard to set CONFIG_BUILTIN_FIRMWARE_DIR to point to
your checkout of the linux-firmware repository, and build your kernel
with _whatever_ firmware you choose. You end up with _more_ choice, not
And on the rare occasion that we really do have an incompatible change
of firmware/kernel interaction from one kernel to the next, it really
isn't difficult to add a version number to the name of the firmware
file, and ship both old and new firmwares in the firmware tree for a
while. That's a bogus argument, even if people _do_ manage to come up
with a better example for it, where their firmware has actually changed
in the last couple of years.
> If you want to argue that that should be in the kernel tarbal itself, you won't
> hear me complain. But others will... and for that a 2nd tarbal might well be the answer.
As soon as we have firmware converted to ihex files in the kernel source
tree, I'll set up a 'shadow' git tree like my kernel-headers tree, which
automatically follows the linux-2.6.git tree commit by commit, and
contains just the results you'd get from 'make firmware_install'.
At that point, when the distributions want to do it separately and
individuals who want to build firmware into their kernel really could
continue to do so _very_ easily, I just don't see any good reason why
we'd continue to keep them together.
to post comments)