From: "H. Peter Anvin" <hpa@zytor.com>
To: Paul Mundt <lethal@linux-sh.org>, Jeff Garzik <jeff@garzik.org>,
Sam Ravnborg <sam@ravnborg.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>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 0/11 v3] enable "make ARCH=x86"
Date: Sat, 10 Nov 2007 12:35:01 -0800 [thread overview]
Message-ID: <473615F5.5090908@zytor.com> (raw)
In-Reply-To: <20071110084447.GA18780@linux-sh.org>
Paul Mundt wrote:
> Indeed, that's what I was intending on keeping around as a convention,
> and simply overloading SRCARCH for the sh64 case. i386/x86_64 potentially
> has the same issue though, and if the intent is to have a single ARCH for
> both of them, I don't see how that would possibly work without
> sacrificing randconfig.. unless the intended x86 convention is that one
> compiler will happily handle both i386 and x86_64 without any difficulty?
Well, that *is* the normal thing on x86.
HOWEVER, I think the right thing for allyesconfig, allmodconfig,
randconfig, etc. is to be able to override specific variables. Right
now, one has to use indirection via a file, which is a bit clumsy; it
would be better if one could do "make allyesconfig CONFIG_X86_64=y" or
somesuch.
In fact, we should be able to get rid of ARCH entirely; CONFIG_ options
have the huge advantage that they're saved in a file, and you don't have
to type them on every make run. The only option that I can't see us
getting rid of easily is HOSTCC, since it is used before config is run,
but probably something clever can be done there, too.
-hpa
next prev parent reply other threads:[~2007-11-10 20:35 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-09 23:08 [PATCH 0/11 v3] enable "make ARCH=x86" Sam Ravnborg
2007-11-09 23:20 ` [PATCH 01/11] x86: unification of cfufreq/Kconfig Sam Ravnborg
2007-11-09 23:20 ` [PATCH 02/11] x86: start unification of arch/x86/Kconfig.* Sam Ravnborg
2007-11-09 23:20 ` [PATCH 03/11] x86: arch/x86/Kconfig.cpu unification Sam Ravnborg
2007-11-09 23:20 ` [PATCH 04/11] x86: add X86_32 dependency to i386 specific symbols in Kconfig.i386 Sam Ravnborg
2007-11-09 23:20 ` [PATCH 05/11] x86: add X86_64 dependency to x86_64 specific symbols in Kconfig.x86_64 Sam Ravnborg
2007-11-09 23:20 ` [PATCH 06/11] x86: copy x86_64 specific Kconfig symbols to Kconfig.i386 Sam Ravnborg
2007-11-09 23:20 ` [PATCH 07/11] x86: move all simple arch settings to Kconfig Sam Ravnborg
2007-11-09 23:20 ` [PATCH 08/11] x86: move the rest of the menu's " Sam Ravnborg
2007-11-09 23:20 ` [PATCH 09/11] x86: enable "make ARCH=x86" Sam Ravnborg
2007-11-09 23:20 ` [PATCH 10/11] x86: drop backward compatibility symlinks to i386/boot and x86_64/boot Sam Ravnborg
2007-11-09 23:20 ` [PATCH 11/11] kbuild: sanity check the specified arch Sam Ravnborg
2007-11-10 3:23 ` [PATCH 0/11 v3] enable "make ARCH=x86" Jeff Garzik
2007-11-10 3:37 ` Randy Dunlap
2007-11-10 3:50 ` Adrian Bunk
2007-11-10 4:05 ` Brian Gerst
2007-11-10 4:12 ` Jeff Garzik
2007-11-14 20:13 ` Roman Zippel
2007-11-10 7:54 ` Sam Ravnborg
2007-11-10 5:26 ` Nick Piggin
2007-11-10 8:21 ` Paul Mundt
2007-11-10 8:24 ` Jeff Garzik
2007-11-10 8:44 ` Paul Mundt
2007-11-10 20:35 ` H. Peter Anvin [this message]
2007-11-10 20:46 ` Sam Ravnborg
2007-11-10 21:24 ` Theodore Tso
2007-11-10 9:39 ` Sam Ravnborg
2007-11-10 10:32 ` david
2007-11-10 9:21 ` Adrian Bunk
2007-11-10 9:26 ` Paul Mundt
2007-11-10 8:23 ` Jeff Garzik
2007-11-10 10:13 ` Adrian Bunk
2007-11-10 15:53 ` Christoph Hellwig
2007-11-12 11:59 ` Frans Pop
[not found] <9nL9f-2n8-11@gated-at.bofh.it>
[not found] ` <9nPcU-bm-3@gated-at.bofh.it>
[not found] ` <9nTqh-6Cw-7@gated-at.bofh.it>
[not found] ` <9nTTh-7w5-7@gated-at.bofh.it>
[not found] ` <9nTTh-7w5-5@gated-at.bofh.it>
[not found] ` <9nUcv-7UA-7@gated-at.bofh.it>
[not found] ` <9o5hA-b8-7@gated-at.bofh.it>
[not found] ` <9o640-1rJ-1@gated-at.bofh.it>
2007-11-11 21:03 ` Bodo Eggert
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=473615F5.5090908@zytor.com \
--to=hpa@zytor.com \
--cc=akpm@linux-foundation.org \
--cc=jeff@garzik.org \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=sam@ravnborg.org \
--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.