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

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/