Re: [PATCH] firmware: Allow release-specific firmware dir

Hi Jeff,

It's definitely not something we should be doing upstream though.
So you think it's ok that every Debian user has to learn this
magic incantation just to use current kernels?

I don't think it's nice to break things like this on people,
especially such a large group. Getting this stuff to work is hard
enough, and we're just putting yet another barrier into the situation
and that can only mean less testers and contributors.

I do know several people who aren't testing and contributing because
the whole firmware shakeup is so bolixed and they really are exasperated
after spending hours trying to get it to work.

it is that the Debian maintainer screwed this up. Upstream never
promoted kernel versioned directories for the firmware. I had a long
discussion with Dave about it at OLS and using the kernel version is
just plain wrong. The driver maintainers should version the firmware if
they break it in an API incompatible way.

They "should," but is that happening now? Out of all the firmware blobs
installed with 2.6.27-rcX, only the edgeport drier actually versions
them - and they're versioned because the driver requires different
versions for different hardware.

let me repeat this, if a driver depends on newer firmware version, then
it should make sure that the firmware itself is versioned. Everything
else will break eventually.

The Intel wireless drivers started to version their firmware a long time
ago. That is the way to go. How will a user tell different firmwares
apart otherwise.

To shed some light into the problem with Debian/Ubuntu. They install the
firmware in /lib/firmware/`uname -r`/ and everytime they bump their ABI
number, they have to install all the firmware again. This is just
braindead. Their udev script actually checks /lib/firmware first and
then the kernel versioned directory. So that is just fine.

Well, what we're doing is including the firmware blobs inside the kernel
packages. So, yeah, we install all the firmware blobs again, but they're
installed with the modules that we're installing all over again anyway.
All the firmware blobs currently included in 2.6.27-rcs total about
540k, so the wasted disk space is largely negligible when compared to
the size of installing an additional kernel and module set.

We check /lib/firmware/$(uname -r) /lib/firmware
/usr/local/lib/firmware, in that order.

Checking /lib/firmware/$(uname -r) is not the issue. The issue is that
when installing a self-compiled kernel, the firmware is not present
in /lib/firmware.

Problem comes when installing let say 2.6.27 since then the firmware
will be looked up in /lib/firmware/ and /lib/firmware/2.6.27/ and
actually it will not be found. Since it is in /lib/firmware/2.6.26-xx/
or something similar.

In what case? After you install a new kernel and then reboot? You have
the same problem with the modules that need the firmware blobs.

If the firmware is not in /lib/firmware (especially external firmware)
it will not be found and the module will be useless if it depends on
that firmware. And the biggest part of the firmware is not distributed
with the kernel because of GPL restrictions. So whatever we decide for
the kernel right now helps nothing if the user needs external firmware
for their devices.

Just take the Intel wireless drivers as an example. If I boot my own
kernel, I have to make sure I either copied or linked them from the
distro directory to /lib/firmware or downloaded them. Whatever the
kernel firmware prefix is makes no difference here.

So having the kernel install everything in /lib/firmware works just fine
with every distro. However looking for firmware that is not shipped with
the kernel, we have a problem since Debian/Ubuntu just not installs it
in the right directory. And there is nothing the kernel can do about it
since it will not touch firmware it doesn't ship. The distro has to fix
their firmware or the users have to place a copy in /lib/firmware/ where
it actually should have been in the first place.

It works just fine until the user wants to install an additional, newer,
kernel and the blob has changed but the filename hasn't.

That is the whole point and Dave and I discussed this deeply. If the
blob changes in an incompatible way or if a driver needs a newer
firmware, the firmware filename should change.

Regards

Marcel


--
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/

Relevant Pages

  • Re: DigiVox A/D TV-Tuner issue
    ... I installed kernel 2.6.25 image and headers and recompiled the v4l-dvb ... I think the last remaining issue is that of the firmware. ... The page below gives some info about USB standards. ... unless you install a later kernel. ...
    (Debian-User)
  • Re: [PATCH] firmware: Allow release-specific firmware dir
    ... promoted kernel versioned directories for the firmware. ... what we're doing is including the firmware blobs inside the kernel ... So, yeah, we install all the firmware blobs again, but they're ...
    (Linux-Kernel)
  • Re: [PATCH] MODULE_FIRMWARE for binary firmware(s)
    ... Your approach is just fine if the things that will need firmware are compiled as modules but some people prefer to build monolithic kernel images, and in those cases there is no way for the kernel to get the firmware as there is no filesystem available yet. ... There is already support in the kconfig for specifying the initramfs source, why culdn't we have the build process fetch any firmware needed by the non-modular portions and store them at the end of the kernel image so that they can be found during boot. ... request_firmware in order to pull in binary firmware blobs from userland ...
    (Linux-Kernel)
  • Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers.
    ... point here that I don't wanna overwrite existing firmware from other ... Especially if modules_install will install the ... Breaking a distro install is worse then breaking a new kernel. ...
    (Linux-Kernel)
  • Re: [PATCH 2/3] firmware: Add CONFIG_BUILTIN_FIRMWARE option
    ... the kernel handles device nodes and on how udev maps them to real ... Please keep in mind that when we created request_firmwaremost of the driver model developers still thought that having class devices was a good idea. ... That has changed and to represent firmware loading in a clean and race free environment where you could load multipl firmwares at the same time for the same driver, ... firmware files inside the kernel. ...
    (Linux-Kernel)