From: Sam Ravnborg <sam@ravnborg.org>
To: Adrian Bunk <bunk@kernel.org>
Cc: Jeff Garzik <jeff@garzik.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
LKML <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 0/5] introduce K64BIT=y and backward compatibility ARCH={i386,x86_64} for x86
Date: Sun, 11 Nov 2007 12:54:53 +0100 [thread overview]
Message-ID: <20071111115453.GA8112@uranus.ravnborg.org> (raw)
In-Reply-To: <20071111050945.GB21669@stusta.de>
On Sun, Nov 11, 2007 at 06:09:45AM +0100, Adrian Bunk wrote:
> On Sat, Nov 10, 2007 at 09:40:38PM +0100, Sam Ravnborg wrote:
>
> > As discussed in another thread the right thing is to add a generic solution
> > to select between 32 and 64 bit - useable for powerpc, s390, ppc et al.
> >...
>
> I seriously question this would be "the right thing".
>
> 32/64bit isn't that special that this and only this option would require
> special casing, and the KISS principle of having only one way to specify
> something like this has it's advantages.
"The right thing" in the correct context.
It was discussed to keep ARCH={i386,x86_64} and the point I have
is that if we are going to extend ARCH=... to be useable to
specify kernel bit size then it should be done in a generic way
and not like it was done before on x86.
I do not consider the discussion about keeping/dropping
ARCH={i386,x86_64} as concluded.
And if we decide on keeping ARCH={i386,x86_64} then I have
questioned the semantics. Clear opinions are missing..
ARCH= semantic
Impact before now
================================================
32/64 bit yes yes
bzImage location yes no
different Kconfig files yes no
decide defconfig yes yes
asm symlink no no
build option yes no [1]
[did I miss anything? I think I did]
[1] ARCH=... select 32/64-bit during configuration.
There is no difference between ARCH={x86,i386,x86_64}
when building the kernel because the 32/64 bit
choice is done at configuration time.
The table above reflect the [now] semantics with the
patches that is present at lkml.
And the patch needed to implment the above
semantic (after the preparational stuff which
is generic) are:
$ git diff --stat HEAD~1..HEAD
Makefile | 18 ++++++++++++++----
arch/x86/Makefile | 8 ++++++--
scripts/kconfig/Makefile | 2 +-
3 files changed, 21 insertions(+), 7 deletions(-)
The scripts/kconfig/Makefile change is a bugfix that maybe
should be included in another patch. It is not x86 specific.
So 19 additional lines and 5 deleted lines to introduce the
ARCH= semantics above.
Sam
next prev parent reply other threads:[~2007-11-11 11:53 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-10 20:40 [PATCH 0/5] introduce K64BIT=y and backward compatibility ARCH={i386,x86_64} for x86 Sam Ravnborg
2007-11-10 20:43 ` [PATCH] kconfig: factor out code in confdata.c Sam Ravnborg
2007-11-10 20:43 ` [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets Sam Ravnborg
2007-11-10 20:43 ` [PATCH] x86: Use CONFIG_64BIT to select between 32 and 64 bit in Kconfig Sam Ravnborg
2007-11-10 20:43 ` [PATCH] kconfig: document make K64BIT=y in README Sam Ravnborg
2007-11-10 20:43 ` [PATCH] x86: introduce ARCH=i386,ARCH=x86_64 to select 32/64 bit Sam Ravnborg
2007-11-10 22:23 ` [PATCH] kconfig: document make K64BIT=y in README Randy Dunlap
2007-11-10 22:18 ` [PATCH] x86: Use CONFIG_64BIT to select between 32 and 64 bit in Kconfig Randy Dunlap
2007-11-10 20:55 ` [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets Guillaume Chazarain
2007-11-11 5:14 ` Adrian Bunk
2007-11-11 12:43 ` Guillaume Chazarain
2007-11-11 13:07 ` Adrian Bunk
2007-11-11 14:59 ` Guillaume Chazarain
2007-11-11 15:30 ` Sam Ravnborg
2007-11-11 15:55 ` Guillaume Chazarain
2007-11-10 22:16 ` Randy Dunlap
2007-11-10 22:31 ` Sam Ravnborg
2007-11-14 20:57 ` Roman Zippel
2007-11-14 22:08 ` Sam Ravnborg
2007-11-15 15:43 ` Roman Zippel
2007-11-15 19:25 ` Sam Ravnborg
2007-11-15 19:43 ` Roman Zippel
2007-11-15 20:45 ` Sam Ravnborg
2007-11-15 21:24 ` Roman Zippel
2007-11-15 22:06 ` Sam Ravnborg
2007-11-16 1:28 ` Roman Zippel
2007-11-16 3:44 ` Randy Dunlap
2007-11-16 13:02 ` Roman Zippel
2007-11-16 5:41 ` Sam Ravnborg
2007-11-16 12:54 ` Roman Zippel
2008-01-06 13:26 ` kconfig: support option env="" [Was: kconfig: use $K64BIT to set 64BIT with all*config targets] Sam Ravnborg
2008-01-14 3:49 ` Roman Zippel
2008-01-14 5:58 ` Sam Ravnborg
2008-01-14 3:50 ` [PATCH 1/3] explicitly introduce expression list Roman Zippel
2008-01-14 3:50 ` [PATCH 2/3] environment symbol support Roman Zippel
2008-01-14 3:51 ` [PATCH 3/3] use environment option Roman Zippel
2007-11-10 22:33 ` [PATCH 0/5] introduce K64BIT=y and backward compatibility ARCH={i386,x86_64} for x86 Randy Dunlap
2007-11-10 22:50 ` Sam Ravnborg
2007-11-11 5:09 ` Adrian Bunk
2007-11-11 11:54 ` Sam Ravnborg [this message]
2007-11-12 2:47 ` Roman Zippel
2007-11-12 5:23 ` 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=20071111115453.GA8112@uranus.ravnborg.org \
--to=sam@ravnborg.org \
--cc=bunk@kernel.org \
--cc=hpa@zytor.com \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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