lkml.org 
[lkml]   [2008]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin"
    On Fri, Jul 04, 2008 at 09:39:36AM -0400, Jeff Garzik wrote:
    > You have been told repeatedly that cp(1) and scp(1) are commonly used to
    > transport the module David and I care about -- tg3. It's been a single
    > file module since birth, and people take advantage of that fact.

    Here, I think I'll have to respectly disagree with you and say that
    you are taking things too far. I don't think scp'ing individual
    modules around counts as an "exported user interface" the same way,
    say "make install; make modules_install" is a commonly understand and
    used interface by users and scripts (i.e., such as Debian's make-kpkg,
    which does NOT know about "make firmware_install", BTW).

    Asking developers that they need to scp an additional module doesn't
    seem terribly onerous to me --- especially if the firmware module is
    much more likely to be static, and probably doesn't need to be changed
    after each compile/edit/debug cycle.

    So on this point I'd side with David, and say that folding "make
    firmware_install" into "make modules_install" goes a long way towards
    healing this particular breakage.

    HOWEVER, as I mentioned in another message, it looks like not all
    forms of mkinitd and/or mkinitramfs scripts deal with /lib/firmware
    correctly, including the one used by the latest version of Ubuntu.
    That to me is a strong argument for either (a) leaving drivers the way
    they are now, or (b) making the new request_firmware() framework be
    able to place the firemware in either the original driver module, or
    in another tg3_firmware.ko module --- which could be unloaded
    afterwards, if people really cared about the non-swappable kernel
    memory being used up.)

    And this is where we pay the price for not having a standard initrd
    generation (with appropriate hooks so that distros could drop in their
    own enhancements) as part of the kernel build process. If we did, it
    would be a lot easier to make sure all distro's learn about new
    requirements that we have imposed on the initrd. Because we haven't,
    initrd's are effectively part of the "exported interface" where we
    have to move slowly enough so that distro's can catch up depending on
    their release schedule. (It also makes it much harder to run a
    bleeding-edge kernel on a release distro system, at least without
    tieing our hands with respect to changes involving the initrd.)

    - Ted


    \
     
     \ /
      Last update: 2008-07-04 16:35    [W:0.033 / U:0.160 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site