Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762922AbYGOTJo (ORCPT ); Tue, 15 Jul 2008 15:09:44 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758004AbYGOTJc (ORCPT ); Tue, 15 Jul 2008 15:09:32 -0400 Received: from srv5.dvmed.net ([207.36.208.214]:38541 "EHLO mail.dvmed.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758282AbYGOTJb (ORCPT ); Tue, 15 Jul 2008 15:09:31 -0400 Message-ID: <487CF5E4.2070400@garzik.org> Date: Tue, 15 Jul 2008 15:09:24 -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> <487CEA73.9000408@garzik.org> <487CF01E.6000208@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: 1484 Lines: 41 Linus Torvalds wrote: > > On Tue, 15 Jul 2008, Jeff Garzik wrote: >> That does not eliminate all problems, because build processes still have >> hardcoded assumptions about outputs. > > Tough. They need to get fixed. > > What's the downside of fixing them, again? Yes, they need fixing. But without firmware-in-module this would be akin to adding kernel module support in version 1.0.1, and forcing all distros to fix their stuff immediately in order to upgrade from version 1.0.0. Permitting firmware-in-module means you do not force each distro, build script, and user immediately into the new regime, with the associated long list of breakage examples. It's just sad because it feels "not the Linux way". The way this was rolled out just feels "harder", far less friendly on the distros -- our customers -- than most other transitions. Not as hard as vmlinuz->kmodule and IDE->libata transitions, I grant, but still not the way we usually do things. Nobody was ever objecting to request_firmware(). It was always about the removal of firmware-in-module and associated forced breakage on distros and build processes. The fallout of _that_ is the rich source of breakage examples I've been pulling from. 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/