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 12:27:00 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Marcel Holtmann <marcel@...tmann.org>
cc:	Frans Pop <elendil@...net.nl>, jeff@...zik.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.

On Tue, 15 Jul 2008, Marcel Holtmann wrote:
> 
> using /lib/firmware/`uname -r`/ is actually not a bad idea. You only
> have to fix udev to actually include this in the list of directories to
> look for firmware files. Also Ubuntu is already doing this.

I really don't think we need to even "fix udev".

Why don't we just load it ourselves? Esepcially as there are probably 
places that try to avoid udev entirely, or at least use a very 
cut-down-version.

We should be fairly trivially able to be _entirely_ backwards compatible 
with any sane setup (not the _sane_ part! It implies that people don't 
copy individual modules around by hand!), with no actual breakage or need 
for distros to even update anything at all - just make the kernel able to 
look up binary blobs in the same place it installed them.

That sounds like the RightThing(tm) to do _regardless_ of any other 
issues, doesn't it? If the kernel installs it in some known place, why 
should it not just read them from that known place?

		Linus
--
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/