public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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