Messages in this thread | | | Subject | Re: [Ksummit-2008-discuss] RFC: Moving firmware blobs out of the kernel. | From | David Woodhouse <> | Date | Fri, 30 May 2008 02:04:18 +0300 |
| |
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 less.
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.
-- dwmw2
| |