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 14:14:47 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
CC:	Frans Pop <elendil@...net.nl>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	arjan@...radead.org, akpm@...ux-foundation.org,
	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.

Henrique de Moraes Holschuh wrote:
> On Tue, 15 Jul 2008, Frans Pop wrote:
>> If I were able to compile firmware into the modules, the problem would be 
>> solved in one go.
> 
> And this thread would have been shorter, even. I hope someone decides to
> write that support instead of complaining ;-)

I've volunteered -- but if Linus and David will reject my code out of 
hand, there is not much point in writing it.


>> [2] As one of the developers for Debian Installer I'm not looking forward 
>> to the complications that is going to cause for us and users.
> 
> That was my point.  These firmware loading changes are good, but there is a
> lot of crap missing (most of it NOT in the kernel) before it can be exposed
> to ordinary users.

100% agreed.

That's the point I've been trying to make all along.

The end goal is good, but it's not at all ready for normal users.


> And without firmware-in-the-module support (which is the ONLY scenario where
> the entire userspace will not notice anything different), this WILL cause
> problem to distros, we will need to scramble up and fix it all before we can
> package 2.6.26.  I don't know if this is a big problem, though.  The work
> will need to be done sooner or later anyway, and we should have enough time
> to do so as long as we don't care for packaging the early -rc.

Agreed.

	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/