From: Roman Zippel <zippel@linux-m68k.org>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
linux-next@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
linuxppc-dev@ozlabs.org
Subject: Re: linux-next: kbuild tree build failure
Date: Thu, 10 Jul 2008 16:52:25 +0200 (CEST) [thread overview]
Message-ID: <Pine.LNX.4.64.0807101623100.6791@localhost.localdomain> (raw)
In-Reply-To: <20080708211930.GA16897@uranus.ravnborg.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
next prev parent reply other threads:[~2008-07-10 14:52 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-07 8:40 linux-next: kbuild tree build failure Stephen Rothwell
2008-07-07 12:51 ` Sam Ravnborg
2008-07-07 13:08 ` Stephen Rothwell
2008-07-07 16:13 ` Roman Zippel
2008-07-07 21:01 ` Sam Ravnborg
2008-07-07 23:36 ` Michael Ellerman
2008-07-08 2:55 ` Roman Zippel
2008-07-10 0:51 ` Michael Ellerman
2008-07-10 14:59 ` Roman Zippel
2008-07-08 21:19 ` Sam Ravnborg
2008-07-10 14:52 ` Roman Zippel [this message]
2008-07-25 4:13 ` Stephen Rothwell
2008-07-26 10:06 ` Sam Ravnborg
2008-07-26 12:40 ` Stephen Rothwell
2008-11-25 4:47 Stephen Rothwell
2008-11-25 8:42 ` Sam Ravnborg
2008-11-25 8:58 ` Stephen Rothwell
2008-11-26 4:42 Stephen Rothwell
2008-11-26 21:06 ` Sam Ravnborg
2008-11-26 23:49 ` Stephen Rothwell
2008-12-03 0:36 ` Stephen Rothwell
2008-12-03 9:46 ` Sam Ravnborg
2009-05-05 1:17 Stephen Rothwell
2009-05-05 6:35 ` Jan Beulich
2009-05-05 6:43 ` Sam Ravnborg
2009-05-05 7:04 ` Jan Beulich
2009-06-09 1:48 Stephen Rothwell
2009-06-09 16:15 ` Sam Ravnborg
2009-06-09 16:19 ` Stephen Rothwell
2009-06-09 21:04 ` Sam Ravnborg
2009-06-09 23:27 ` Stephen Rothwell
2009-10-14 1:20 Stephen Rothwell
2009-10-14 7:43 ` Sam Ravnborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0807101623100.6791@localhost.localdomain \
--to=zippel@linux-m68k.org \
--cc=linux-next@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=sam@ravnborg.org \
--cc=sfr@canb.auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).