linux-kernel - Re: [bug?] tg3: Failed to load firmware "tigon/tg3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 04 Jul 2008 10:06:19 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	David Woodhouse <dwmw2@...radead.org>,
	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"

Alan Cox wrote:
>> Why is it so difficult to see the value of KEEPING STUFF WORKING AS IT 
>> WORKS TODAY?
> 
> Sure Jeff. Lets delete libata, that caused all sorts of problems when it
> was being added. We could freeze on linux 1.2.13-lmp, that was a good
> release - why break it ?
> 
> There are good sound reasons for having a firmware tree, the fact tg3 is
> a bit of dinosaur in this area doesn't make it wrong.

I never said it was wrong.

I have said repeatedly that separating out the firmware is the right 
thing to do.

But...  you don't need to force the switchover.  You don't need to break 
things that work today, in order to accomplish this.

It is quite feasible to do both -- keep things working as they work 
today, _and_ add /lib/firmware infrastructure.  Then we can work to 
switch distros over to the new system.

Further, it is not only feasible, but the only "nice" thing to do to 
other developers, users, and distros:  permit them to choose when to 
stop the decades-old practice of building firmware into some drivers.

Perform the transition in a sane, staged, planned manner that doesn't 
result in tons of non-working drivers.  I have already provided many 
real world examples where people, doing the same things they do today, 
will be greeted with non-working drivers upon the next boot.  Without 
any warning or error messages along the way, hinting that something 
might be wrong.

Or, for the cheap seats:

	End goal: good

	dwmw2's current path:  very easy to produce dead driver

	Needed resolution:  first step should /not/ produce regressions;

			    current evidence demonstrates current
			    implementation is full of regressions
			    that seasoned kernel hackers are hitting

It /is/ possible to add /lib/firmware gadgetry while avoiding the 
obvious low-hanging-fruit regressions and flag-day conversions that have 
been pointed out here.

Just say no to flag-day changes like this.  It is possible for each 
distro and boot image script to have their own flag-day.  Give them that 
choice.

	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/