Re: RFC: Moving firmware blobs out of the kernel.

From: Jeff Garzik
Date: Thu May 29 2008 - 15:13:43 EST


David Woodhouse wrote:
I'm kind of hoping that this is going to be one of those topics that
resolves itself -- but just in case it isn't, I'd like to discuss it at
the kernel summit:

I'd like to remove all firmware blobs from the kernel source tree.

With the intention of making that less contentious, I've done the
following:

I've added support to the firmware loader for finding firmware in a
special section of the static kernel, so that using request_firmware()
no longer forces you to use an initrd or udev. You can build _arbitrary_
firmware files into your kernel, if you want to. Whether you're allowed
to distribute the resulting vmlinux or not is still a question you ought
to ask your lawyer.

I'm working on converting drivers over to use request_firmware(), and
shifting their firmware blobs into .ihex files in a firmware/ directory
of the source tree. For each one, I'm giving the option of continuing to
build it in statically, using the above mechanism.

I've implemented a 'make firmware_install' Kbuild target, which takes
all those firmware blobs and installs them somewhere where udev can load
them on request.

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.


I like your idea, all the way to the point where you actually remove the firmware file from the kernel tree :)

I think it's a good move to make the firmware files standalone and not #include'd as a C header file, but it's just plain easier to ship them with the kernel tree in a lot of cases. $FOO-firmware packages in Fedora prove other methods of firmware distribution are quite usable, but that does not therefore imply that in-kernel built-in firmwares have no utility.

Personally, living in an imaginary all-open-source world, I wouldn't mind seeing firmware source for firmware built into drivers, a la drivers/scsi/aic7xxx/aicasm/, living in the kernel tree.

If the firmware has a compatible license and is required for critical operations like booting the machine, built-in firmware should remain an option. For certain embedded cases, I could certainly see that in-kernel firmware being the best method for firmware distribution, for both $Platform's users and $Platform's developers.

Jeff



--
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/