Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel,use it in more drivers.

From: Linus Torvalds
Date: Mon Jul 14 2008 - 22:09:42 EST




On Mon, 14 Jul 2008, david@xxxxxxx 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/