Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757244AbYGOSeJ (ORCPT ); Tue, 15 Jul 2008 14:34:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758786AbYGOSdk (ORCPT ); Tue, 15 Jul 2008 14:33:40 -0400 Received: from srv5.dvmed.net ([207.36.208.214]:52491 "EHLO mail.dvmed.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758737AbYGOSdi (ORCPT ); Tue, 15 Jul 2008 14:33:38 -0400 Message-ID: <487CED7C.4060401@garzik.org> Date: Tue, 15 Jul 2008 14:33:32 -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> <487C585C.2060002@garzik.org> <487CD7FE.9010209@garzik.org> <487CDEC0.3090004@garzik.org> <487CE85D.8050107@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: 1244 Lines: 39 Linus Torvalds wrote: > > On Tue, 15 Jul 2008, Jeff Garzik wrote: >> Can't you see that changing build processes takes time? Fixing driver disk >> creation tools take time? Validating that each driver is packaged with its >> correct firmware takes time? > > Umm. Can't you see that if we don't start doing it, it will never get done > AT ALL? > > Yes, this will take time. Which, by implication, means that userland is not -already- prepared. Which means that if you don't have a recent userland of a mainstream distro, the result is non-working drivers. Which is the type of regression I thought we did not want. > But that's not an argument for not merging it. Quite the reverse. This is not an either/or proposition, and that is what you are missing. The change should go in _while at the same time_ not creating regressions. The change is not the problem. That the change exists without the ability to recreate similar outputs (i.e. firmware in module) is the problem. 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/