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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 14 Jul 2008 23:15:20 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	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 Mon, 14 Jul 2008, Jeff Garzik wrote:
>> My complaints are about --not breaking stuff--, not request_firmware().
> 
> Guys, request_firmware() has been around for about five years now.
> 
> If this discussion had happened in 2003, I'd agree.
> 
> As it is, I think it's time to just face it - many people do want to have 
> a unified interface (and yes, I obviously count myself in that group), and 
> you can't just continue do nothing and ignore that.
> 
> Your argument seems to be that you don't want to break anything, but 
> you've also clearly not wanted to _fix_ anything for the last five years. 
> 
> At some point, somebody has to just do it. And five years is _way_ long 
> enough.

In threads of years past, you've agreed with the plainly obvious -- 
built-in firmware is obviously more reliable, and is more likely to 
produce a working driver.

It doesn't break anything to keep this feature.

Keeping this feature doesn't prevent any other fixes.

Keeping this feature closes the window for potential regressions.

And keeping this feature means Linux users can make a _choice_, rather 
than forcing /lib/firmware on them.

Do you really think embedded system and micro distro authors are in 100% 
agreement that /lib/firmware is best for their situation?  Really?

	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/