lkml.org 
[lkml]   [2008]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers.
    On Tue, 15 Jul 2008, Frans Pop wrote:
    > So then I build 2.6.27-rc1 and install it. Great.
    >
    > You release 2.6.27-rc2 and I build it. Ouch! It fails to install, at least
    > if I want to install it _alongside_ 2.6.27-rc1 or other kernels (which I
    > do!). Why does it fail? Because dpkg's package management does not allow
    > one package to overwrite files already "owned" by another package.

    I believe I read in the previous thread that some distros are already using
    /lib/firmware/<kernel version>/.

    There was also the suggestion of moving the entire set of kernel-packaged
    firmware to /lib/modules/<kernel version>/firmware, probably while keeping
    /lib/firmware as a second place to look for firmware so that we don't hose
    any system.

    > If I were able to compile firmware into the modules, the problem would be
    > solved in one go.

    And this thread would have been shorter, even. I hope someone decides to
    write that support instead of complaining ;-)

    But I do feel we still need a smarter userspace firmware loader to make
    firmware packaging less insane. The "current aproach" you described, with
    one firmware per package, is not good. It doesn't allow for multiple
    versions of the firmware to be installed should you need it.

    > I don't know how the Debian kernel team plans to deal with this for distro
    > kernel packages. They probably _do_ want to keep them separate [2]. Maybe
    > by grouping firmware for really common drivers into
    > firmware-basic-drivers or something along those lines.

    I sure hope we go with the more proper fix (a version-enabled firmware
    loader that can do the unversioned /lib/firmware as well). It is far more
    resilient in the long run.

    > [1] Only quick solution I see is to have it install the firmware in a
    > versioned directory and have the postinst copy things from there to
    > /lib/firmware.

    Yuck. That would work only if you never needed two active copies of the
    kernel [with different firmware files] active at the same time.

    > [2] As one of the developers for Debian Installer I'm not looking forward
    > to the complications that is going to cause for us and users.

    That was my point. These firmware loading changes are good, but there is a
    lot of crap missing (most of it NOT in the kernel) before it can be exposed
    to ordinary users.

    And without firmware-in-the-module support (which is the ONLY scenario where
    the entire userspace will not notice anything different), this WILL cause
    problem to distros, we will need to scramble up and fix it all before we can
    package 2.6.26. I don't know if this is a big problem, though. The work
    will need to be done sooner or later anyway, and we should have enough time
    to do so as long as we don't care for packaging the early -rc.

    --
    "One disk to rule them all, One disk to find them. One disk to bring
    them all and in the darkness grind them. In the Land of Redmond
    where the shadows lie." -- The Silicon Valley Tarot
    Henrique Holschuh


    \
     
     \ /
      Last update: 2008-07-15 20:09    [W:0.029 / U:63.544 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site