From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756179AbZJSNYx (ORCPT ); Mon, 19 Oct 2009 09:24:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756090AbZJSNYx (ORCPT ); Mon, 19 Oct 2009 09:24:53 -0400 Received: from kroah.org ([198.145.64.141]:41216 "EHLO coco.kroah.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755586AbZJSNYw (ORCPT ); Mon, 19 Oct 2009 09:24:52 -0400 Date: Mon, 19 Oct 2009 06:22:05 -0700 From: Greg KH To: Carmelo Amoroso Cc: Alan Jenkins , Linux Kernel Mailing List , Rusty Russell , linux-kbuild Subject: Re: Fast LKM symbol resolution with SysV ELH hash table Message-ID: <20091019132205.GA7192@kroah.com> References: <4ADACD3A.9020803@gmail.com> <9b2b86520910180544g94ecc8fuf0d7849e18cd8937@mail.gmail.com> <20091018214704.GA26592@kroah.com> <2ccd6e3c0910190445va8ff4a8x94dc4044ac01057d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2ccd6e3c0910190445va8ff4a8x94dc4044ac01057d@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 19, 2009 at 01:45:20PM +0200, Carmelo Amoroso wrote: > Just a few other notes. The current implementation I did based on SysV > has a drawback that is not backward compatible, so you cannot use old > modules with a kernel with the option enabled due to changes on struct > kernel_symbol. Why would this be a problem? Whenever making a kernel config change, you should be able to rebuild everything, as lots of other configuration options are that way. > Anyway I've just figured out how to change it to remove this limitation. > I need some time to review these patches. Further, the newer > implementation based on GNU hash which we are working on right now, > will not require the extra .undef.hash ELF sections because hash > values are already embedded into the GNU hash table, with a reduction > in terms of footprint. Footprint in the memory for the loaded module, or just in the footprint for the module on the disk? I'd be interested in seeing your patches when you have something that works for the current Linus kernel tree. thanks, greg k-h