[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <487CF5E4.2070400@garzik.org>
Date: Tue, 15 Jul 2008 15:09:24 -0400
From: Jeff Garzik <jeff@...zik.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: david@...g.hm, Arjan van de Ven <arjan@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
David Woodhouse <dwmw2@...radead.org>,
alan@...rguk.ukuu.org.uk, linux-kernel@...r.kernel.org
Subject: Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel,
use it in more drivers.
Linus Torvalds wrote:
>
> On Tue, 15 Jul 2008, Jeff Garzik wrote:
>> That does not eliminate all problems, because build processes still have
>> hardcoded assumptions about outputs.
>
> Tough. They need to get fixed.
>
> What's the downside of fixing them, again?
Yes, they need fixing.
But without firmware-in-module this would be akin to adding kernel
module support in version 1.0.1, and forcing all distros to fix their
stuff immediately in order to upgrade from version 1.0.0.
Permitting firmware-in-module means you do not force each distro, build
script, and user immediately into the new regime, with the associated
long list of breakage examples.
It's just sad because it feels "not the Linux way".
The way this was rolled out just feels "harder", far less friendly on
the distros -- our customers -- than most other transitions. Not as
hard as vmlinuz->kmodule and IDE->libata transitions, I grant, but still
not the way we usually do things.
Nobody was ever objecting to request_firmware(). It was always about
the removal of firmware-in-module and associated forced breakage on
distros and build processes. The fallout of _that_ is the rich source
of breakage examples I've been pulling from.
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists