Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756208AbYGODP4 (ORCPT ); Mon, 14 Jul 2008 23:15:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756883AbYGODPh (ORCPT ); Mon, 14 Jul 2008 23:15:37 -0400 Received: from srv5.dvmed.net ([207.36.208.214]:52342 "EHLO mail.dvmed.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756744AbYGODPg (ORCPT ); Mon, 14 Jul 2008 23:15:36 -0400 Message-ID: <487C1648.5070409@garzik.org> Date: Mon, 14 Jul 2008 23:15:20 -0400 From: Jeff Garzik User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Linus Torvalds CC: 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> <487C0365.5030203@garzik.org> <487C09EB.1050903@garzik.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: 1564 Lines: 43 Linus Torvalds wrote: > > On Mon, 14 Jul 2008, Jeff Garzik wrote: >> My complaints are about --not breaking stuff--, not request_firmware(). > > Guys, request_firmware() has been around for about five years now. > > If this discussion had happened in 2003, I'd agree. > > As it is, I think it's time to just face it - many people do want to have > a unified interface (and yes, I obviously count myself in that group), and > you can't just continue do nothing and ignore that. > > Your argument seems to be that you don't want to break anything, but > you've also clearly not wanted to _fix_ anything for the last five years. > > At some point, somebody has to just do it. And five years is _way_ long > enough. In threads of years past, you've agreed with the plainly obvious -- built-in firmware is obviously more reliable, and is more likely to produce a working driver. It doesn't break anything to keep this feature. Keeping this feature doesn't prevent any other fixes. Keeping this feature closes the window for potential regressions. And keeping this feature means Linux users can make a _choice_, rather than forcing /lib/firmware on them. Do you really think embedded system and micro distro authors are in 100% agreement that /lib/firmware is best for their situation? Really? 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/