On Thu, 2008-05-29 at 15:12 -0400, Jeff Garzik wrote:
quoted text
> 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.

I certainly agree, pushing more and more into initrd just annoys the
hell out of me.

I'd argue to include everything needed to build (and esp cross build) an
initrd into the kernel - up until that point initrds are useless.


--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/