Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757776AbZKCBgE (ORCPT ); Mon, 2 Nov 2009 20:36:04 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755716AbZKCBgD (ORCPT ); Mon, 2 Nov 2009 20:36:03 -0500 Received: from fanny.its.uu.se ([130.238.4.241]:57496 "EHLO fanny.its.uu.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753578AbZKCBgC (ORCPT ); Mon, 2 Nov 2009 20:36:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19183.35067.828412.651217@pilspetsen.it.uu.se> Date: Tue, 3 Nov 2009 02:35:55 +0100 From: Mikael Pettersson To: david@lang.hm Cc: Krzysztof Halasa , Alan Cox , "Ryan C. Gordon" , =?ISO-8859-15?Q?M=E5ns_Rullg=E5rd?= , linux-kernel@vger.kernel.org Subject: Re: FatELF patches... In-Reply-To: References: <1257103201.2865.6.camel@chumley> <20091102000147.424f104b@lxorguk.ukuu.org.uk> <20091102091611.60dfeea1@lxorguk.ukuu.org.uk> X-Mailer: VM 7.17 under Emacs 20.7.1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1957 Lines: 40 david@lang.hm writes: > > FatELF means you have to compile for many archs. Do you even have the > > necessary compilers? Extra time and disk space used for what, to solve > > a non-problem? > > you don't have to compile multiple arches anymore than you have to provide > any other support for that arch. FatELF is a way to bundle the binaries > that you were already creating, not something to force you to support an > arch you otherwise wouldn't (although if it did make it easy enough for > you to do so that you started to support additional arches, that would be > a good thing) 'bundle' by gluing .o files together rather than using what we already have: directories, search paths, $VARIABLES in search paths, and ELF interpreters and .so loaders that know to look in $ARCH subdirectories first (I used that feature to perform an incremental upgrade from OABI to EABI on my ARM/Linux systems last winter). Someone, somewhere, has to inspect $ARCH and make a decision. Moving that decision from user-space to kernel-space for ELF file loading is neither necessary nor sufficient. Consider .a and .h files for instance. > > I'm surprised this idea made it here. It certainly has merit for > > installation medium, but it's called directory tree and/or .tar or .zip > > there. > > if you have a 1M binary with 500M data, repeated for 5 arches it is not a > win vs a single 505M FatELF package in all cases. If I have a 1M binary with 500M non-arch data I'll split the package because I'm not a complete moron. IMNSHO FatELF is a technology pretending to be a solution to "problems" that don't exist or have user-space solutions. Either way, it doesn't belong in the Linux kernel. -- 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/