Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755365AbZKBPON (ORCPT ); Mon, 2 Nov 2009 10:14:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755257AbZKBPON (ORCPT ); Mon, 2 Nov 2009 10:14:13 -0500 Received: from icculus.org ([67.106.77.212]:40528 "EHLO icculus.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755256AbZKBPON (ORCPT ); Mon, 2 Nov 2009 10:14:13 -0500 Date: Mon, 2 Nov 2009 10:14:15 -0500 (EST) From: "Ryan C. Gordon" X-X-Sender: icculus@caridad.icculuslan To: Valdis.Kletnieks@vt.edu cc: =?ISO-8859-15?Q?M=E5ns_Rullg=E5rd?= , linux-kernel@vger.kernel.org Subject: Re: FatELF patches... In-Reply-To: <63587.1257137919@turing-police.cc.vt.edu> Message-ID: References: <1257103201.2865.6.camel@chumley> <63587.1257137919@turing-police.cc.vt.edu> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2060 Lines: 50 > > think if Ubuntu did this as a distribution-wide policy, then people would > > probably choose a different distribution. > > Hmm.. so let's see - people compiling stuff for themselves won't use this > feature. And if a distro uses it, users would probably go to a different > distro. I probably wasn't clear when I said "distribution-wide policy" followed by a "then again." I meant there would be backlash if the distribution glued the whole system together, instead of just binaries that made sense to do it to. And, again, there's a third use-case besides compiling your programs and getting them from the package manager, and FatELF is meant to address that. > Actually, they can't nuke the /lib{32,64} directories unless *all* binaries > are using FatELF - as long as there's any binaries doing things The Old Way, > you need to keep the supporting binaries around. Binaries don't refer directly to /libXX, they count on ld.so to tapdance on their behalf. My virtual machine example left the dirs there as symlinks to /lib, but they could probably just go away directly. > Don't forget you take that hit once for each shared library involved. Plus That happens in user space in ld.so, so it's not a kernel problem in any case, but still...we're talking about, what? Twenty more branch instructions per-process? > I'm not sure if there's hidden gotchas lurking in there (is there code that > assumes that if executable code is mmap'ed, it's only done so in one arch? The current code sets up file mappings based on the offset of the desired ELF binary. > Or will a FatELF glibc.so screw up somebody's refcounts if it's mapped > in both 32 and 64 bit modes? Whose refcounts would this screw up? If there's a possible bug, I'd like to make sure it gets resolved, of course. --ryan. -- 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/