[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <486E2818.1060003@garzik.org>
Date: Fri, 04 Jul 2008 09:39:36 -0400
From: Jeff Garzik <jeff@...zik.org>
To: David Woodhouse <dwmw2@...radead.org>
CC: Andi Kleen <andi@...stfloor.org>,
David Miller <davem@...emloft.net>, tytso@....edu,
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"
David Woodhouse wrote:
> On Fri, 2008-07-04 at 09:15 -0400, Jeff Garzik wrote:
>> However, there is still a broken element to the system: the firmware no
>> longer rides along in the module's .ko file. That introduces new
>> problems for any user and script that copies modules around.
>>
>> The compiled-in firmware should be in the same place where it was before
>> your changes -- in the driver's kernel module.
>
> No, Jeff. That is neither new, nor a real problem. You're just
> posturing.
>
> That's the way it has been for a _long_ time anyway, for any modern
> driver which uses request_firmware(). The whole point about modules is
> _modularity_. Yes, that means that sometimes they depend on _other_
> modules, or on firmware.
>
> The scripts which handle that kind of thing have handled inter-module
> dependencies, and MODULE_FIRMWARE(), for a long time now.
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.
Therefore, logically, you have introduced additional dependencies and
regressions into what was once a single-file copy.
If you wish to hand-wave away what developers and users do today as
posturing, that's up to you...
How difficult is it to see that you must create a system that LET'S
PEOPLE CHOOSE whether or not they like your stuff.
Why are you so hell-bent on removing choice?
Why is it so difficult to see the value of KEEPING STUFF WORKING AS IT
WORKS TODAY?
Doing so (a) keeps developers happy, (b) GUARANTEES no regressions, and
(c) in no way excludes /lib/firmware, moving firmware to userspace.
Sheesh.
Let developers, users, and distros endorse your plan on their own
schedule. Stop forcing your choices down our throats.
Jeff
--
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