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:	Tue, 15 Jul 2008 15:09:24 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	david@...g.hm, 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 Tue, 15 Jul 2008, Jeff Garzik wrote:
>> That does not eliminate all problems, because build processes still have
>> hardcoded assumptions about outputs.
> 
> Tough. They need to get fixed.
> 
> What's the downside of fixing them, again?

Yes, they need fixing.

But without firmware-in-module this would be akin to adding kernel 
module support in version 1.0.1, and forcing all distros to fix their 
stuff immediately in order to upgrade from version 1.0.0.

Permitting firmware-in-module means you do not force each distro, build 
script, and user immediately into the new regime, with the associated 
long list of breakage examples.

It's just sad because it feels "not the Linux way".

The way this was rolled out just feels "harder", far less friendly on 
the distros -- our customers -- than most other transitions.  Not as 
hard as vmlinuz->kmodule and IDE->libata transitions, I grant, but still 
  not the way we usually do things.

Nobody was ever objecting to request_firmware().  It was always about 
the removal of firmware-in-module and associated forced breakage on 
distros and build processes.  The fallout of _that_ is the rich source 
of breakage examples I've been pulling from.

	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/