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: <1216150288.27242.75.camel@violet.holtmann.net>
Date:	Tue, 15 Jul 2008 21:31:28 +0200
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Linus Torvalds <torvalds@...ux-foundation.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.

Hi Linus,

> > 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".

fixing udev means adding an extra path to it :)

> 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?

Personally I am against hacking file loading from within the kernel.
This is why we involved udev (or hotplug in the beginning). It allows
you to have userspace policy for the search paths etc.

Regards

Marcel


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