Re: loading firmware while usermodehelper disabled.

[david]

On Tue, 3 Jan 2012, Alexander E. Patrakov wrote:

> Matthew Garrett <mjg@xxxxxxxxxx> wrote:
>
> > On Mon, Jan 02, 2012 at 01:27:03PM -0800, Linus Torvalds wrote:
> >
> > > If we didn't load the firmware before the suspend, then the resume
> > > function of a device sure as hell had better not load it at resume
> > > time either.
> >
> > If the hardware has lost its state then refusing to load the firmware
> > at resume time isn't going to leave you with a working device.
> >
> > > And for chrissake, don't bother making it more complicated than it
> > > is, just for some theoretical hardware or situation that nobody
> > > cares about.
> >
> > It's not theoretical hardware. This appears to be the current
> > behaviour of the isight devices. If you reboot they retain their
> > firmware. If you suspend, they don't. So if we have a flow like this:
> >
> > 1) user boots from cold. Device comes up with generic USB ID.
> > 2) isight_firmware loads and binds. Firmware is loaded. Device
> > disconnects and reconnects with an ID that's bound by the UVC driver.
> > 3) user reboots. Device comes up with UVC ID. isight_firmware doesn't
> > bind.
> > 4) user suspends.
> > 5) user resumes. isight_firmware binds and attempts to load firmware.
> >
> > then just caching the firmware is inadequate - we had never
> > previously seen the device on this boot, so we've never loaded it in
> > order to cache it. isight_firmware could unconditionally load the
> > firmware on module load just in case a device is plugged in, but that
> > seems even less elegant than caching it.
>
> What a heated discussion due to, essentially, a non-technical, legal
> issue! Remember that the whole "userspace firmware loader" saga
> together with the asynchronous firmware interface started when Debian
> started complaining over the non-freeness of the firmware being bundled
> as a part of the kernel module as an array of bytes. That design,
> however, never had such dependency issues. So maybe revert to it, with
> the following changes, and solve the legal issue seen by Debian by
> hiring a lawyer?

at the very least, there should be a simple compile option that says 
'compile any firmware that may be needed into the kernel/module image' so 
that those of us who are not worried about the distribution of firmware 
blobs (or who don't believe that just splitting the firmware blobs into 
a separate tree gains anything) can just opt out of this entire mess. As I 
see it, today we have the option of manually specifying firmware blobs to 
compile in, but no easy way to just include them all.

> 1. Make firmware a special case of a data-only non-GPL kernel module.
> Change the tainter so that it doesn't taint the kernel for data-only
> modules.
> 2. Make the actual driver depend on the relevant firmware modules for
> all devices supported by it, even if the devices don't always need the
> said firmware.
> 3. Disallow building drivers that need firmware as non-modules.

Please do not do this one.

David Lang

> 4. Do something (e.g. split the driver into a core and a shim, or make
> a fake firmware module) to allow the user to install without firmware
> if he knows that it works with his hardware.
> 5. Profit!
>
> This way, as long as the driver is loaded, the necessary firmware is
> also there, as a dependency.
--
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/