Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin"

[Theodore Tso <tytso@mit.edu>]

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