Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756218AbYGOH5f (ORCPT ); Tue, 15 Jul 2008 03:57:35 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753763AbYGOH51 (ORCPT ); Tue, 15 Jul 2008 03:57:27 -0400 Received: from srv5.dvmed.net ([207.36.208.214]:57057 "EHLO mail.dvmed.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750942AbYGOH51 (ORCPT ); Tue, 15 Jul 2008 03:57:27 -0400 Message-ID: <487C585C.2060002@garzik.org> Date: Tue, 15 Jul 2008 03:57:16 -0400 From: Jeff Garzik User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Linus Torvalds CC: david@lang.hm, Arjan van de Ven , Andrew Morton , David Woodhouse , alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org Subject: Re: [GIT *] Allow request_firmware() to be satisfied from in-kernel, use it in more drivers. References: <1216077806.27455.85.camel@shinybook.infradead.org> <20080714164119.99c33d5b.akpm@linux-foundation.org> <20080714165956.7fe2d4ee@infradead.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-Spam-Report: SpamAssassin version 3.2.5 on srv5.dvmed.net summary: Content analysis details: (-4.4 points, 5.0 required) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1505 Lines: 42 Linus Torvalds wrote: > On Mon, 14 Jul 2008, david@lang.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. Agreed. > 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. A more complex, multi-file inter-dependent system is more reliable than a single-file driver with built-in firmware, doing the same thing? Come _on_. There are good arguments for request_firmware(), but that ain't it. > 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. Agreed. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/