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]

Message-ID: <487C09EB.1050903@garzik.org>
Date:	Mon, 14 Jul 2008 22:22:35 -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:
>> IMO the newly added /inability/ to build firmware into kernel modules is a
>> clear regression.
> 
> IMO you're being stupid.
> 
> How about explainign why it makes any difference what-so-ever?
> 
> If you can load the module, you can load the firmware. Claiming anything 
> else is just _stupid_.

False -- for every router build script, driver disk build script, etc. 
that has not yet been updated to copy both a module and the 
/lib/firmware that the kernel tree is newly spitting out.

And for every case, the breakage is completely silent, until one boots 
into a firmware-less image and loads drivers.

> And if you cannot see the advantage of having _one_ interface to firmware 
> loading, instead of each driver picking a random approach, I don't know 
> what to say.

It's a great approach!  As I've said over and over and over (and now 
over) again.

My complaints are about --not breaking stuff--, not request_firmware().

You have to look at the build process, second stage image builders, 
embedded system image creators, and other "hangers on" that do not look 
and behave like a mainstream Linux distro.

It is a mistake to assume that all systems are _already_ prepared to 
install and digest new /lib/firmware files that the kernel build now 
spits out.

And the consequences of that assumption is a non-working driver, often a 
non-booting system, not just a few quirks here and there.

	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/