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: <alpine.DEB.1.10.0807141944210.6370@asgard>
Date:	Mon, 14 Jul 2008 19:47:56 -0700 (PDT)
From:	david@...g.hm
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	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.

On Mon, 14 Jul 2008, Linus Torvalds wrote:

> On Mon, 14 Jul 2008, david@...g.hm wrote:
>
>> On Mon, 14 Jul 2008, Linus Torvalds wrote:
>>>
>>> That's a totally bogus argument.
>>
>> you misunderstood me. the people pushing request_firmware() are doing so on
>> the basis that they won't have to use kernel ram to hold the firmware. the
>> people pushing for having the option of building the firmware into the module
>> are acknowleding that this may use a little more ram, but they see it as being
>> more reliable.
>
> I'm just saying that it's a totally bogus argument to claim that it takes
> less memory - Either way.
>
> As to reliability, I don't buy that, especially with a generic interface,
> and with a way to link the thing in-kernel anyway. Using common
> infrastructure is going to be more reliable.
>
>>> I don't know why people get confused about this. I suspect that people
>>> kind of expect that since they need to reload the firmware when resuming
>>> the device, they should also do the "request_firmware()" at resume time.
>>
>> according to David W they would, becouse the driver would not keep the
>> firmware in kernel memory after it's initialized
>
> And if so, David W is a total moran, and shouldn't have been doing this.
>
> The fact is, there _are_ good arguments for request_firmware(), but they
> have nothing what-so-ever to do with memory use or anything like that.
>
> The argument for request_firmware() is that it's a good _single_ interface
> to the whole firmware issue, allowing us to split up the driver from the
> firmware without every driver having to do some hack of its own.

I don't think anyone objects to request_firmware() as a common interface. 
they object to forcing the firmware to be seperate.

in the monolithic kernel case the people pushing this bowed to preasure 
and improved request_firmware() so that the firmware could be embedded in 
the kernel image as opposed to the initial approach of requireing an 
initramfs.

Jeff and David M are arguing that it should be possible to also embed the 
firmware into the module .ko file. If that option was available I don't 
think there would be opposition to having the one interface. the lack of 
that option is causing them to object and point out cases where it's not 
as good as previously.

David Lang

> Not memory use.
>
> So next time you see somebody arguing about memory use (either way), just
> slap them, and tell them Linus told you to.
>
> 			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/