From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from pasmtpB.tele.dk (pasmtpb.tele.dk [80.160.77.98]) by ozlabs.org (Postfix) with ESMTP id BC3FDDDF03 for ; Wed, 9 Jul 2008 07:18:45 +1000 (EST) Date: Tue, 8 Jul 2008 23:19:30 +0200 From: Sam Ravnborg To: Roman Zippel Subject: Re: linux-next: kbuild tree build failure Message-ID: <20080708211930.GA16897@uranus.ravnborg.org> References: <20080707184038.aaeb8d40.sfr@canb.auug.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Cc: Stephen Rothwell , linux-next@vger.kernel.org, Paul Mackerras , linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi Roman. I thought a bit more about this. > I should have gone through all archs to test this, sorry about that. > Luckily it's only powerpc that uses 64bit values. I would prefer to > standardize on 32bit values, as it doesn't really make sense to expect > from the user to input full 64bit values and it's easy to generate the > full value in a header. We use Kconfig for a mixture of user editable values and fixed configuration values. And I agree that asking the user to input a 64 bit number is not usefull. But keeping support for 64 bit values is what I would consider expected functionality. So removing support for 64 bit is not good IMO. > This would also ease on any portability issues > (kconfig is compiled with the host compiler not the target compiler). We use strtol() in a few places in symbol.c already where we do an implicit conversion to int. Why did this not cause us problems before? Is it because these code paths are only triggered when we deal with ranges? If so we could 'fix' strdup_type() to not use strto{,u}l() so it is 64 bit clean and we are back to old behaviour. Sam