Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764163AbYF3UkZ (ORCPT ); Mon, 30 Jun 2008 16:40:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753353AbYF3UkL (ORCPT ); Mon, 30 Jun 2008 16:40:11 -0400 Received: from terminus.zytor.com ([198.137.202.10]:48816 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753187AbYF3UkK (ORCPT ); Mon, 30 Jun 2008 16:40:10 -0400 Message-ID: <486943F1.80606@zytor.com> Date: Mon, 30 Jun 2008 13:37:05 -0700 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Sam Ravnborg CC: Ingo Molnar , Kamalesh Babulal , Stephen Rothwell , linux-next@vger.kernel.org, LKML , Jens Axboe , Andy Whitcroft , Thomas Gleixner , Ingo Molnar , Vivek Goyal , "Eric W. Biederman" Subject: Re: [BUILD-FAILURE] linux-next: Tree for June 30 References: <20080701001656.e156585c.sfr@canb.auug.org.au> <48690385.7030500@linux.vnet.ibm.com> <48690D3C.1060803@linux.vnet.ibm.com> <20080630185943.GA24692@uranus.ravnborg.org> <20080630192610.GA6584@elte.hu> <20080630194727.GA26682@uranus.ravnborg.org> <20080630200623.GE6584@elte.hu> <20080630202506.GA28050@uranus.ravnborg.org> In-Reply-To: <20080630202506.GA28050@uranus.ravnborg.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1466 Lines: 36 Sam Ravnborg wrote: >> ah, ok. So the patch below should solve this for now? >> >> is there any particular reason why we are limited to 100 sections? (is >> there some ELF limitation here perhaps?) > > I would still like to know if you see significant different numbers than Kamalesh. > If you see a number close to 100 then OK. > But if you see a number say in the range of below 80 then we should dive deeper into this. > > I do not even know what the program does - never looked at it befoe > so why the original limit was 100 I dunno. > It looks to me that the people who did the relocatable kernel code just put in a magic number. There is certainly no inherent reason for this limit. What's really ugly is that this is in a host-space program! It would have been one thing if it had been in a piece of code run in a restricted environment, e.g. in the decompressor, but this one runs in user space on the build environment. The quick solution is to change this number to something obscenely big (say 10000, but even that could be an issue if we end up doing stuff like section per function); the proper solution is to turn these arrays into a structure and allocate the array dynamically. -hpa -- 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/