It seems that David Woodhouse had a bit of an ulterior motive when he recently
reworked the kernel firmware
loader. That is not to say the work is not useful in its own right,
but one of his goals is more apparent now: removing all of the firmware
kernel source tree. By making it easy to separate the firmware
blobs—while still allowing them to be statically built into
kernels—he has provided a possible path for all firmware needed by
any Linux driver to live in a single place.
The firmware issue is somewhat contentious, with licensing and political
issues that tend to annoy the kernel developers. Arguments about the
"legality" of distributing firmware with the kernel flare up from time to
time. Separate from that, there are some good reasons why it makes sense
to keep the firmware in its own place: some distributions need or want to
distribute their kernels without firmware blobs and some hardware
manufacturers will not allow their firmware to be distributed with the
kernel because of concerns about the GPL. The current situation makes it
harder for both users and distributors.
Woodhouse brought up the idea of pulling the firmware out of the kernel in
a post to linux-kernel and
ksummit-2008-discuss. The agenda for this year's Kernel Summit is
under discussion, so he proposed that it be discussed there. He is clearly
trying to anticipate the technical concerns that others might have:
By the time the kernel summit comes around, we should have made decent
progress on moving _all_ the firmware blobs to the firmware/ directory.
And at that point I'd like to remove them completely, to a separate git
tree and tarball. Those who really want to build them in to their static
kernel would still be able to, but it wouldn't be the default behaviour.
Unsurprisingly, there are some fairly strenuous objections. David Miller
is quite annoyed:
Sorry, that's taking things too far. I've fought, like, forever, to
keep the tg3 driver with it's firmware in-tree. I refuse to let the
driver get broken like that, it's staying working, and that means
in-tree and linked into the driver.
If debian or whoever else have these concerns and want to rip the
firmware out, it is one hundred percent their problem to patch things
out of the kernel tree they use.
But there are other reasons to collect firmware in one single place, as
Arjan van de Ven notes:
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
side of things easier.
If you want to argue that that should be in the kernel tarball itself, you
hear me complain. But others will... and for that a 2nd tarball might well
be the answer.
Just we shouldn't need 100 tarballs.
There is a very real concern, though, that putting firmware without source
into the kernel is a GPL violation. It is impossible to know for sure
without a court decision, which is something that no one wants to have to
deal with. Companies—and their lawyers—tend to be very
conservative when it comes to inviting lawsuits, so removing unrelated,
possibly actionable code from the kernel sources is of great benefit to
them. As Woodhouse says:
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.
By making it easier to put all of the firmware in one non-GPL tree,
hardware vendors—and their lawyers—may be willing to
allow the firmware to be distributed. If Woodhouse's plan for supporting
both compile-time and runtime loading of the firmware is successful and
reasonably transparent, there
should be little difference for kernel developers, but big improvements for
users and distributors. It is unclear whether this is something that will
be resolved in email, as Woodhouse hopes, or will require a discussion at
the Kernel Summit in September, but it's an idea with a lot of merit that
may find its way into the mainline at some point.
to post comments)