All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.