LWN: Comments on "Firmware loading and suspend/resume"

Firmware loading and suspend/resume

jackb — Sat, 22 Sep 2012 13:33:08 +0000

Another cool feature is that if you are trying to build a non-modular driver that requires firmware that's included in the kernel sources, and have KBUILD_OUTPUT set compilation will fail due to a "not found" error until you manually copy the firmware directory to $KBUILD_OUTPUT

Firmware loading and suspend/resume

nix — Fri, 21 Sep 2012 22:49:55 +0000

I pretty much concur. The userspace loader causes problems even when it isn't being used at all. e.g. I just got a new machine with a Barts GPU in it (ATI Radeon 6870), and since I have a largely non-modular kernel with KMS built in I put all the firmware I thought it would need into CONFIG_EXTRA_FIRMWARE. I forgot one file... so the system hung for something like sixty seconds(!) trying to call out to userspace to load the firmware -- even though PID 1 had not yet been forked off! Of course because this was brand-new hardware and it was right at modesetting time I thought I'd messed something up in the .config or there was something major missing in the kernel's KMS support or something like that.

The whole thing is a complete trainwreck, from the need to dig through source code to find the right names to jam in CONFIG_EXTRA_FIRMWARE through the userspace loading that you can use except in unusual situations such as if you have even a single firmware-using module built into the kernel or if you need even a single firmware-using module to resume from hibernation. (Oh, and how much assistance does the kernel give you in detecting that you have either of those situations? None, that's how much. It just dies without a message at the appropriate time. IIRC there's been talk about fixing the hibernation side of this, but I don't think anything ever came of it.)

This whole thing was designed entirely to let distro vendors produce something without violating the GPL, and it does that -- but unfortunately it makes it bloody hard for the rest of us to produce working systems without digging through the source code if we have anything needing firmware at all, even if we're not using modules for anything.

(Sorry, Matthew, I really don't like to criticise your work -- but this banjaxed-up firmware-loading mess just wasted several hours of my time hunting for a 'lockup' that wasn't, due to a hugely overlong timeout that even the stupidest kernel should not have incurred, on a kernel with no loadable firmware of any sort, before userspace was even running. This is not something that has been tested in the non-modular case with an eye to not being intolerably awful.)

Firmware loading and suspend/resume

iive — Thu, 20 Sep 2012 23:19:28 +0000

There might be a(nother) case where this new mechanism won't work.

If you attach USB device while the system is suspended, on resume the usb-core would find it and probe a driver for it. That driver would try to load a firmware, but because it have never been loaded before it won't be found in the "cache".

Honestly, why is userland even involved in firmware loading? The whole userland shenanigan should be scraped and reverted to the old system where the kernel loads the firmware directly from the filesystem. If the kernel modules are accessible, then the firmware would be accessible too. (Use tmpfs or initrd as workarounds for the other cases.)

KiSS.

Firmware loading and suspend/resume

mpr22 — Fri, 17 Aug 2012 12:49:23 +0000

more varieties of beer

Well, more brands of pale lager, anyway :)

Firmware loading and suspend/resume

felixfix — Fri, 17 Aug 2012 04:19:37 +0000

I'm going to clutter this up with an off-topic comment. It tickles me pink to see more and more non-US/Euro names show up as contributors. I realize Ming Lei may well be a US or EU citizen or resident, but the more "non-traditional" names show up, the more likely they come from all over the world, and that just makes me smile.

I also realize this comment could easily come off sounding rather strange and perhaps be taken wrongly, so maybe I can forestall some of that by saying again that I like this perceived change, and if I am slow to perceive it, if it has been obvious to everyone else for years and years, well, pardon me, but it still strikes me as a positive sign in so many ways that I can't help but smile and think the world is becoming a better place in many ways: Linux, free source software, expanding horizons, less poverty from the spread of technology, world peace, and more varieties of beer spreading around the world as tokens of code appreciation.

Firmware loading and suspend/resume

JohnLenz — Thu, 16 Aug 2012 06:28:54 +0000

Firmware loading happens through udev. The kernel raises a hotplug event which udev sees. See this README. On Ubuntu, /lib/udev/rules.d/50-firmware contains the udev rule, which runs the /lib/udev/firmware binary whenever the kernel requests a firmware file.

The reason is because the kernel can run in strange environments: read only root file system, running with containers with locked down root filesystems, etc. With filesystem namespaces, there is no single filesystem so the kernel has no idea where to look for files. Even calling into custom filesystem code from somewhere else in the kernel is somewhat icky. Instead the kernel just requests userspace take care of it.

Firmware loading and suspend/resume

kugel — Thu, 16 Aug 2012 05:18:31 +0000

I'm surprised to hear that firmware loading depends on user space, on a helper process in particular. Does that refer to FUSE or something else?