[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1215270632.10393.864.camel@pmac.infradead.org>
Date: Sat, 05 Jul 2008 16:10:32 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Olivier Galibert <galibert@...ox.com>
Cc: Andi Kleen <andi@...stfloor.org>, Takashi Iwai <tiwai@...e.de>,
Hannes Reinecke <hare@...e.de>, Theodore Tso <tytso@....edu>,
Jeff Garzik <jeff@...zik.org>,
David Miller <davem@...emloft.net>, hugh@...itas.com,
akpm@...ux-foundation.org, kosaki.motohiro@...fujitsu.com,
mchan@...adcom.com, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, netdev@...r.kernel.org
Subject: Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin"
On Sat, 2008-07-05 at 16:44 +0200, Olivier Galibert wrote:
> On Sat, Jul 05, 2008 at 01:16:06PM +0100, David Woodhouse wrote:
> > It almost never happens that you have kernel versions which _need_
> > different firmware installed. In almost all cases, the older driver will
> > continue to work just fine with the newer firmware (and its bug-fixes).
>
> I'm not sure which planet you're from, but it's one without ipw2200
> chips in it. And in any case, the file names change.
I was speaking of the firmware which is currently in-kernel. ipw2200 is
a recent driver and uses request_firmware() already, so isn't affected
at all when I update other, older drivers. As such, it's not
particularly relevant to this discussion.
The drivers which we're updating to use request_firmware() have _not_
changed their firmware very often at all -- and even _less_ frequently
have they done so in an incompatible fashion.
> > The ABI between driver and firmware rarely changes in such a fashion
> > that you have to update the driver in lock-step -- and even on the
> > occasions that it does, it's not hard to simply change the name of the
> > "new-style" firmware so that it doesn't stomp on the old one (Think of
> > it like an soname).
>
> Ah, I see, you just didn't read the thread you're replying to. Let's
> do it again one more time.
>
> The question is, how do you sanely distribute the kernel-tree
> generated firmware in a binary distribution, knowing that you want to
> be able to have multiple working kernels installed simultaneously?
<...>
> Solution 2: in a package by itself
Probably this one. That package can be seeded from a git repo which is
automatically derived from the contents of the firmware/ directory in
Linus' tree, and can add the other firmware blobs which are available in
various places -- the ones that the owners won't let us include in the
kernel tree due to the GPL, but _will_ allow us to distribute in a
separate firmware repository.
> -> You either break compatibility with kernel versions that happened
> before a firmware change, or you accumulate tons of files over
> time. The accumulated form gets hard to create from source.
On the rare occasions that a firmware changes incompatibly, you'd want
to keep both old and new versions in the firmware tree for a reasonable
period of time. But since that doesn't happen very often, it isn't a
particularly difficult issue to handle. I strongly believe that you are
overestimating the scale of the problem -- and it would only be a
problem for the person maintaining the firmware repository anyway. I'm
perfectly content to do that job.
--
dwmw2
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists