From: "Alexander E. Patrakov" <patrakov@gmail.com>
To: linux-wireless@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org
Subject: Re: loading firmware while usermodehelper disabled.
Date: Tue, 3 Jan 2012 15:16:37 +0600 [thread overview]
Message-ID: <20120103151637.1388e204@home> (raw)
In-Reply-To: <20120102215028.GA15701@srcf.ucam.org>
Matthew Garrett <mjg@redhat.com> 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?
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.
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.
--
Alexander E. Patrakov
next prev parent reply other threads:[~2012-01-03 9:40 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20111230235421.GA6054@redhat.com>
2011-12-31 0:22 ` loading firmware while usermodehelper disabled Linus Torvalds
2011-12-31 0:40 ` Matthew Garrett
2011-12-31 15:33 ` Alan Stern
2011-12-31 15:59 ` Oliver Neukum
2012-01-01 2:21 ` Alan Stern
2012-01-01 12:22 ` Oliver Neukum
2012-01-01 16:17 ` Alan Stern
2012-01-01 16:25 ` Michael Büsch
2012-01-01 20:30 ` Linus Torvalds
2012-01-01 21:27 ` Oliver Neukum
2012-01-01 21:39 ` Michael Büsch
2012-01-02 3:33 ` Matthew Garrett
2012-01-02 7:56 ` Oliver Neukum
2012-01-02 4:17 ` Marek Vasut
2012-01-02 5:35 ` Gábor Stefanik
2012-01-02 8:38 ` Marek Vasut
2012-01-02 16:54 ` Alan Stern
2012-01-02 20:41 ` Jack Stone
2012-01-02 20:48 ` Linus Torvalds
2012-01-02 20:55 ` Jack Stone
2012-01-02 21:00 ` Linus Torvalds
2012-01-02 21:09 ` Jack Stone
2012-01-02 21:23 ` Linus Torvalds
2012-01-02 21:31 ` Jack Stone
2012-01-02 21:52 ` Marek Vasut
2012-01-02 21:57 ` Jack Stone
2012-01-02 22:31 ` Marek Vasut
2012-01-02 23:25 ` Jack Stone
2012-01-03 0:31 ` Marek Vasut
2012-01-03 0:44 ` Jack Stone
2012-01-03 0:58 ` Alan Cox
2012-01-03 7:17 ` Marek Vasut
2012-01-03 7:41 ` Oliver Neukum
2012-01-03 0:35 ` Alan Cox
2012-01-03 0:50 ` Alan Cox
2012-01-02 21:19 ` Matthew Garrett
2012-01-02 21:26 ` Jack Stone
2012-01-03 0:42 ` Alan Cox
2012-01-03 11:57 ` Oliver Neukum
2012-01-03 12:19 ` Jack Stone
2012-01-03 13:20 ` Alan Cox
2012-01-03 13:30 ` Oliver Neukum
2012-01-03 13:36 ` Alan Cox
2012-01-02 21:27 ` Linus Torvalds
2012-01-02 21:50 ` Matthew Garrett
2012-01-02 22:03 ` Linus Torvalds
2012-01-02 22:12 ` Matthew Garrett
2012-01-02 22:19 ` Linus Torvalds
2012-01-02 22:29 ` Matthew Garrett
2012-01-02 22:46 ` Linus Torvalds
2012-01-02 23:00 ` Matthew Garrett
2012-01-02 23:31 ` Jack Stone
2012-01-03 0:13 ` Matthew Garrett
2012-01-03 0:20 ` Alan Cox
2012-01-03 0:37 ` Matthew Garrett
2012-01-03 0:22 ` Jack Stone
2012-01-03 0:31 ` Alan Cox
2012-01-03 0:41 ` Jack Stone
2012-01-03 0:38 ` Matthew Garrett
2012-01-03 0:47 ` Alan Cox
2012-01-03 0:18 ` Alan Cox
2012-01-03 8:26 ` Ingo Molnar
2012-01-03 2:45 ` Alan Stern
2012-01-03 3:25 ` Matthew Garrett
2012-01-03 5:53 ` Linus Torvalds
2012-01-03 11:50 ` Oliver Neukum
2012-01-03 15:16 ` Alan Stern
2012-01-03 12:24 ` Matthew Garrett
2012-01-03 16:29 ` Linus Torvalds
2012-01-03 15:09 ` Alan Stern
2012-01-03 9:16 ` Alexander E. Patrakov [this message]
2012-01-03 9:24 ` david
2012-01-03 13:43 ` Alan Cox
2012-01-03 14:12 ` Bernd Petrovitsch
2012-01-03 0:00 ` Alan Cox
2012-01-02 23:50 ` Alan Cox
2012-01-02 23:53 ` Alan Cox
2011-12-31 16:27 ` Matthew Garrett
2011-12-31 14:20 ` Martin Schleier
2011-12-31 18:39 ` Marek Vasut
2012-01-01 9:48 ` Oliver Neukum
2012-01-01 9:54 ` Marek Vasut
2012-01-01 12:28 ` Oliver Neukum
2012-01-01 16:32 ` Marek Vasut
2012-01-01 17:06 ` Marek Vasut
2012-01-01 20:39 ` Alan Cox
2012-01-01 20:50 ` Michael Büsch
2012-01-02 3:24 ` Marek Vasut
2012-01-02 3:29 ` Marek Vasut
2012-01-01 3:49 ` Larry Finger
2012-01-01 22:45 ` Jack Stone
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120103151637.1388e204@home \
--to=patrakov@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).