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: <487C142E.8000207@keyaccess.nl>
Date:	Tue, 15 Jul 2008 05:06:22 +0200
From:	Rene Herman <rene.herman@...access.nl>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	David Miller <davem@...emloft.net>, david@...g.hm,
	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 15-07-08 04:39, Linus Torvalds wrote:

> On Mon, 14 Jul 2008, David Miller wrote:
>> They states that it was being done on a technical basis rather
>> than being predominantly a legal one.
> 
> No.
> 
> Yes, the original reason for request_firmware() was obviously very much 
> partly legal.
> 
> HOWEVER.
> 
> Once you have a model that is required (for whatever reasons) for some 
> drivers, we're much better off using the _same_ model for all drivers, 
> whether it is necessary for legal reasons for those other drivers.
> 
> Put this way: if you do a distro, you _need_ to support firmware loading 
> anyway. And once you do that, it's just annoying how some drivers then do 
> something odd and special for the same thing, for no real good reason.

There's little alternative infrastructure in declaring a static array of 
unsigned char though.

Yes, it still makes sense to make everyone use request_firmware() if 
only because these other drivers now all of a sudden have a more 
accessible way of updating their firmwares, but David's objective is 
legal here.

Which is fine.

But the very clear _technical_ objection about this not providing for 
keeping modules and their firmware together for those that really do 
want it to be that way was not at all addressed. Note, this while still 
using request_firmware(), just at the option of the kernel builder with 
the firmware compiled into the module. Right now, this allows the 
firmware to be compiled into the vmlinux only which makes fairly little 
sense if the driver itself is a module.

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