Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762144AbYGOSMG (ORCPT ); Tue, 15 Jul 2008 14:12:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754883AbYGOSLz (ORCPT ); Tue, 15 Jul 2008 14:11:55 -0400 Received: from srv5.dvmed.net ([207.36.208.214]:39837 "EHLO mail.dvmed.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754142AbYGOSLy (ORCPT ); Tue, 15 Jul 2008 14:11:54 -0400 Message-ID: <487CE85D.8050107@garzik.org> Date: Tue, 15 Jul 2008 14:11:41 -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> 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: 1975 Lines: 47 Linus Torvalds wrote: > > On Tue, 15 Jul 2008, Linus Torvalds wrote: >> This is the "I'm too stupid to live" argument. I've already answered that. >> What's so hard with "make firmware_install"? > > Btw, that is by no means the only way to handle it either. As I said in > other emails - about trying to find _productive_ questions to answer - > maybe we could also just install it in the modules directory or some > similar per-kernel location, and just teach request_firmware() to load > binary blobs directly. > > Then - horror of horrors - we could even make "make modules_install" do > things like that automatically for you with some Makefile rule trickery. > > See? There are _productive_ things you can do or ask others to do. > > But singing the same "I'm so stupid that I cannot install the firmware" > song over and over again doesn't make me think you are worth listening to. 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? With each driver converted, it is entirely possible that all users are completely unaware that it even had a firmware, much less that it now needs 'make firmware_install' to continue working. If one is completely unaware of a driver's firmware need, (a) you don't know you need to install it and (b) you don't find out you need it until you boot and the driver fails to work. I am trying to work to minimize (a) and (b) here, because as deployed, there are large chances for failure here, across a random selection of drivers. Jeff P.S. AFAIK, 'make modules_install' installs firmware, unless that change was not pushed upstream. -- 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/