From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roman Zippel Subject: Re: linux-next: kbuild tree build failure Date: Thu, 10 Jul 2008 16:52:25 +0200 (CEST) Message-ID: References: <20080707184038.aaeb8d40.sfr@canb.auug.org.au> <20080708211930.GA16897@uranus.ravnborg.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20080708211930.GA16897@uranus.ravnborg.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linuxppc-dev-bounces+glppd-linuxppc64-dev=m.gmane.org@ozlabs.org Errors-To: linuxppc-dev-bounces+glppd-linuxppc64-dev=m.gmane.org@ozlabs.org To: Sam Ravnborg Cc: Stephen Rothwell , linux-next@vger.kernel.org, Paul Mackerras , linuxppc-dev@ozlabs.org List-Id: linux-next.vger.kernel.org Hi, On Tue, 8 Jul 2008, Sam Ravnborg wrote: > 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. Isn't that a bit of a stretch? That's a rather generic argument, do we really have to keep everything, because someone _might_ want to use it? I'd rather look at how useful it really is to keep that functionality and so far we exactly one user, which doesn't strictly require it. So far it's more a convenience feature rather than a required feature. We don't lose any functionality, it's just shifted from kconfig to the header file. > > 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. Ranges are the primary reason I made it consistent with this. If we really wanted to support 64bit numbers, it would create only more problems. First you have to make sure that on every build host (i.e also non-Linux) strtoll() is available. Then how it should these numbers be represented? On 32bit these may need a 'll' postfix, but the powerpc example already shows, that there are different requirements, so they use ASM_CONST for that. How should this postprecessing be integrated into kconfig? I would seriously prefer to keep things as simple as possible, unless there is a real requirement for it, but so far there isn't any. If we really needed something like this, I'd rather introduce a new expression type, which works more like an unquoted string (e.g. you could define something like (1l<<$PAGE_SHIFT)), where things like ranges wouldn't work, but it also wouldn't have any content restrictions. bye, Roman