Plan for tomorrows (20080522) FESCO meeting

[Dave Jones]

On Thu, May 22, 2008 at 09:24:17AM +0100, David Woodhouse wrote:

 > >   # SND_KORG1212 - Korg 1212 IO
 > >   clean_ifdef sound/pci/korg1212/korg1212.c CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL
 > >   clean_blob sound/pci/korg1212/korg1212-firmware.h
 > > 
 > >   # SND_MAESTRO3 - ESS Allegro/Maestro3
 > >   clean_ifdef sound/pci/maestro3.c CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL
 > > 
 > >   # SND_YMFPCI - Yamaha YMF724/740/744/754
 > >   clean_blob sound/pci/ymfpci/ymfpci_image.h
 > >   clean_ifdef sound/pci/ymfpci/ymfpci_main.c CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL
 > > 
 > > clean_blob() removes long sequences of numbers, whereas clean_ifdef()
 > > runs unifdef on the named file assuming the named variable is
 > > undefined.
 > > 
 > > Could you honestly tell me, with a straight face and a reasonable
 > > degree of assurance, that a patch that performs these actions stands
 > > any chance whatsoever of being accepted upstream?
 > 
 > I'll tell you what I'd do to _improve_ its chances. Would that do?
 > 
 > What I'd do is augment the kernel's firmware class support so that users
 > can build firmware blobs into their kernel to be accessed through the
 > firmware class. So the ifdefs in the above code go away -- the user can
 > just choose to include the blobs in the kernel build or not, as they see
 > fit, and the driver just invokes the firmware loader and doesn't
 > actually _care_ whether the firmware comes from within the kernel or
 > from userspace.

It's even easier than that. The drivers mentioned above _already_ have
firmware loader support.  All that's needed is for someone to convert
those arrays into an actual file the firmware loader can read, and
package it up in an rpm, along with udev scripts to auto-load it,
and we can disable that CONFIG option in the kernel.

	Dave

-- 
http://www.codemonkey.org.uk