Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751953AbZJWWYJ (ORCPT ); Fri, 23 Oct 2009 18:24:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751579AbZJWWYI (ORCPT ); Fri, 23 Oct 2009 18:24:08 -0400 Received: from claw.goop.org ([74.207.240.146]:39192 "EHLO claw.goop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751351AbZJWWYH (ORCPT ); Fri, 23 Oct 2009 18:24:07 -0400 Message-ID: <4AE22D04.50708@goop.org> Date: Fri, 23 Oct 2009 15:24:04 -0700 From: Jeremy Fitzhardinge User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: "Ryan C. Gordon" CC: linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH 2/2] binfmt_elf: FatELF support for kernel modules. References: <4ADD0086.9060304@goop.org> In-Reply-To: X-Enigmail-Version: 0.97a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1405 Lines: 32 On 10/19/09 21:54, Ryan C. Gordon wrote: > I can understand that concern, but I worry about refusing to take steps > that would aid free software developers in case it might help the > closed-source people, too. > Any open source driver should be encouraged to be merged with mainline Linux so there's no need to distribute them separately. With the staging/ tree, that's easier than ever. I don't see much upside in making it "easier" to distribute binary-only open source drivers separately. (It wouldn't help that much, in the end; the modules would still be compiled for some finite set of kernels, and if the user wants to use something else they're still stuck.) > Those that will behave badly will do so regardless of file formats, but > distros shipping nothing but GPL'd software and in-tree drivers would > benefit from this more than another misguided company that probably > doesn't care about multiple CPU architectures anyhow. > Well, ideally a fat module would allow modules for multiple kernels to be bundled together (same and/or different architectures), which is primarily useful for 3rd-party binary distributions. J -- 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/