[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071110101324.GK26163@stusta.de>
Date: Sat, 10 Nov 2007 11:13:24 +0100
From: Adrian Bunk <bunk@...nel.org>
To: Jeff Garzik <jeff@...zik.org>
Cc: Sam Ravnborg <sam@...nborg.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 0/11 v3] enable "make ARCH=x86"
On Sat, Nov 10, 2007 at 03:23:32AM -0500, Jeff Garzik wrote:
> Sam Ravnborg wrote:
>> Keeping ARCH=i386 and ARCH=x86_64 around is just a way to pretend
>> this is two diffrent architectures which is no longer the case.
>
> They _are_ different in the real world... that's why
>
> make ARCH=i386
>
> is so often used.
I for one use i386 simply because I do not have any computer that would
support 64bit. But when I'll see a 32/64bit question during
"make oldconfig" I'll also know what to answer.
>> Do we need a way to say "build a kernel that is 64 bit"?
>> If we need this then we should look at the most intuitive way
>> to say so and this should work across x86, powerpc and s390.
>>
>> make 64BIT=y ARCH=x86
>>
>> looks so much more intuitive. And it is generic.
>> This is just a proposal.
>
> Or the short and straightforward
>
> make ARCH=x86_64
>
> to do the same thing (and incidentally what we've been doing up until this
> point).
>
> Don't get so hung up on "architecture" and actually look at what people do
> _today_.
>
> All other solutions proposed are simply _longer_ ways to do exact the same
> thing. "more work for same outcome" isn't optimal.
Let's check who the "people" affected are:
Aunt Tillie isn't affected since she doesn't compile her own kernel.
People compiling kernels have to learn that the choice went from
ARCH={i386,x86_64} to a Kconfig option. I'd say it's more consistent
that the 32/64bit question is now handled the same way as the
K6/K7/K8/... question. And there doesn't seem to be any "longer" or
"more work" in this case.
What's left are kernel developers who have not read the toplevel README
and who do therefore not know about KCONFIG_ALLCONFIG. Getting people to
write documentation is a hard task, but it's only second to getting
people to read documentation....
And although you might argue that you have a few characters more to type
when using KCONFIG_ALLCONFIG it has the advantage that it's generic,
and it e.g. allows you to create a CONFIG_X86_32=y, CONFIG_SMP=n
allyesconfig configuration.
> Jeff
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists