Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932256AbWBXPaW (ORCPT ); Fri, 24 Feb 2006 10:30:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932274AbWBXPaW (ORCPT ); Fri, 24 Feb 2006 10:30:22 -0500 Received: from smtpq2.tilbu1.nb.home.nl ([213.51.146.201]:50402 "EHLO smtpq2.tilbu1.nb.home.nl") by vger.kernel.org with ESMTP id S932256AbWBXPaW (ORCPT ); Fri, 24 Feb 2006 10:30:22 -0500 Message-ID: <43FF26A8.9070600@keyaccess.nl> Date: Fri, 24 Feb 2006 16:30:48 +0100 From: Rene Herman User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "Eric W. Biederman" CC: Linus Torvalds , Arjan van de Ven , Andi Kleen , linux-kernel@vger.kernel.org, akpm@osdl.org, mingo@elte.hu Subject: Re: Patch to reorder functions in the vmlinux to a defined order References: <1140700758.4672.51.camel@laptopd505.fenrus.org> <1140707358.4672.67.camel@laptopd505.fenrus.org> <200602231700.36333.ak@suse.de> <1140713001.4672.73.camel@laptopd505.fenrus.org> <43FE0B9A.40209@keyaccess.nl> <43FE1764.6000300@keyaccess.nl> <43FE4B00.8080205@keyaccess.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AtHome-MailScanner-Information: Neem contact op met support@home.nl voor meer informatie X-AtHome-MailScanner: Found to be clean Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1040 Lines: 25 Eric W. Biederman wrote: > The page table trickery is actually the more invasive approach. I > believe for 32 bit kernels the real problem is giving up the identity > mapping of low memory. Yes, you probably don't want to have to specialcase anything there. > Short of the moving the kernel to end of the address space where > vmalloc and the fixmaps are now I don't think there is a reasonable > chunk of the address space we can use. To my handwaving ears end of the address space sounds very good though. Is there currently any pressure on VMALLOC_RESERVE (128M)? Teaching the linker appears to be a matter of changing __KERNEL_START. That leaves actually mapping ourselves there, and... more invasiveness? I saw you say you already have some actual relocating patches though? Rene. - 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/