[lkml]   [2008]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] firmware: Allow release-specific firmware dir
Hash: SHA1

Marcel Holtmann wrote:
> Hi Dave,
>>> 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.

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

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

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

- -Jeff

- --
Jeff Mahoney
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE -


 \ /
  Last update: 2008-09-11 10:17    [W:0.096 / U:6.628 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site