linux-kernel - Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers.

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 15 Jul 2008 13:54:57 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	David Woodhouse <dwmw2@...radead.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.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:
>> The changes are good,
>>
>> They just don't need to break stuff.
>>
>> Which they do.
> 
> If you were serious about that, then you'd be suggesting _fixes_.

The fix was suggested from day one:  permit firmware-in-module, which 
I've already said I will work on...  provided its not dead on arrival.

Other fixes I've stated in these threads I want to tackle:

* newly separated firmware should live alongside the driver

* driver author should be able to deliver binary firmware direct from 
vendor, without any ihex or C-source-code mangling.


> I'm not seeing you do that. I'm just seeing non-productive "we should 
> never have changed" emails.

The emails are "this change should not contain obvious breakages"

To review the parts you've apparently missed, the problems and 
regressions I have found during review were

- Kconfig produced non-working drivers.  10+ skilled kernel hackers hit 
this.  I complained, was called silly, pointless, and having a tantrum. 
  Then, the issue was fixed, and kernel hackers could boot again.

- the normal build process produced non-working drivers.  A couple more 
skilled kernel hackers hit this one.  Build process regression was 
OBVIOUS.  Again, fixing this was called pointless and silly.  Again, it 
got fixed.  Again, kernel hackers started working again.

Now we have one last major regression hole to fix -- firmware-in-module.


> See my emails about what can be _productive_ avenues to explore. As it is, 
> I have yet to see a _single_ productive email from you. 

Strange, considering that it has been me who pointed out problems that 
would -- and did -- hit other kernel hackers, and those problems after 
much complaining and insulting got fixed.

	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/