This patchset unify the i386 and x86_64 Kconfig
files for x86.
In addition it replaces the use of ARCH=i386 and
ARCH=x86_64 with the more intuitive ARCH=x86.
The primary purpose of this patch serie is to
enable make ARCH=x86 and let the config decide
if we are building for 32 or 64 bit.
But we will break quite a high number of
scripts with this change.
What is the desired behaviour when specifying:
make ARCH=i386
and
make ARCH=x86_64
??
For now it just error out like this:
$ make ARCH=i386
Makefile:503: /home/sam/kernel/x86.git/arch/i386/Makefile: No such file or directory
make: *** No rule to make target `/home/sam/kernel/x86.git/arch/i386/Makefile'. Stop.
What is the required functionality here?
Note - only patch 9 and 10 are changing any behaviour.
So if we decide to keep current functionality then
the first 8 patches still makes a lot of sense.
The patch serie contains:
Sam Ravnborg (10):
x86: unification of cfufreq/Kconfig
x86: start unification of arch/x86/Kconfig.*
x86: arch/x86/Kconfig.cpu unification
x86: add X86_32 dependency to i386 specific symbols in Kconfig.i386
x86: add X86_64 dependency to x86_64 specific symbols in Kconig.x86_64
x86: copy x86_64 specific Kconfig symbols to Kconifg.i386
x86: add remaning bits from x86_64 to Kconfig.i386
x86: combine all config options with prompts in Kconfig
x86: select i386 or x86_64 at config time
x86: enable make ARCH=x86
The diffstat looks promising:
9 files changed, 975 insertions(+), 2639 deletions(-)
A patch that makes the kernel more than 1500 line smaller
is a good patch!
Full diffstat (as git can show it):
$ git diff --stat -C -M -B HEAD~10..HEAD
Makefile | 5 +-
arch/x86/{Kconfig.i386 => Kconfig} | 600 ++++----
arch/x86/Kconfig.cpu | 83 +-
arch/x86/Kconfig.i386 | 1609 ++++----------------
arch/x86/Kconfig.x86_64 | 1132 ++++----------
arch/x86/Makefile | 2 +-
.../x86/kernel/cpu/cpufreq/{Kconfig_32 => Kconfig} | 68 +-
arch/x86/kernel/cpu/cpufreq/Kconfig_64 | 108 --
scripts/kconfig/Makefile | 7 +-
9 files changed, 975 insertions(+), 2639 deletions(-)
The serie can be pulled from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/sam/x86.git
Patches will follow in seperate thread.
This serie replaces the single patch I posted the other day.
This serie are made to ease review and to do so a few of the patches
does not change functionality but are just preparing for later steps.
Sam
On Sun, 4 Nov 2007 00:48:26 +0100
Sam Ravnborg <[email protected]> wrote:
> This patchset unify the i386 and x86_64 Kconfig
> files for x86.
> In addition it replaces the use of ARCH=i386 and
> ARCH=x86_64 with the more intuitive ARCH=x86.
>
> The primary purpose of this patch serie is to
> enable make ARCH=x86 and let the config decide
> if we are building for 32 or 64 bit.
>
> But we will break quite a high number of
> scripts with this change.
> What is the desired behaviour when specifying:
> make ARCH=i386
> and
> make ARCH=x86_64
I would say.. just print a very very nasty warning, wait 20 seconds,
and then pretend it was passed as x86
and then remove in the next release (assuming the code isn't too ugly)
other than that.. just break it now in 2.6.24; people at least remember
.24 as the release that unified, so they expect changes there... they
won't expect them for .25 or later
On Sat, Nov 03, 2007 at 04:52:47PM -0700, Arjan van de Ven wrote:
> On Sun, 4 Nov 2007 00:48:26 +0100
> Sam Ravnborg <[email protected]> wrote:
>
> > This patchset unify the i386 and x86_64 Kconfig
> > files for x86.
> > In addition it replaces the use of ARCH=i386 and
> > ARCH=x86_64 with the more intuitive ARCH=x86.
> >
> > The primary purpose of this patch serie is to
> > enable make ARCH=x86 and let the config decide
> > if we are building for 32 or 64 bit.
> >
> > But we will break quite a high number of
> > scripts with this change.
> > What is the desired behaviour when specifying:
> > make ARCH=i386
> > and
> > make ARCH=x86_64
>
> I would say.. just print a very very nasty warning, wait 20 seconds,
> and then pretend it was passed as x86
> and then remove in the next release (assuming the code isn't too ugly)
I'd suggest exit'ing after printing a helpful note.
The user will anyway have to adjust his build environment, so let's make
a clear cut now.
> other than that.. just break it now in 2.6.24; people at least remember
> .24 as the release that unified, so they expect changes there... they
> won't expect them for .25 or later
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
Sam Ravnborg wrote:
> This patchset unify the i386 and x86_64 Kconfig
> files for x86.
> In addition it replaces the use of ARCH=i386 and
> ARCH=x86_64 with the more intuitive ARCH=x86.
>
> The primary purpose of this patch serie is to
> enable make ARCH=x86 and let the config decide
> if we are building for 32 or 64 bit.
Yuck, I dislike. Please don't take away this nice development workflow.
the current workflow of
make ARCH=i386 allmodconfig && make ARCH=i386 -sj5
no longer works. Now, the new and ungainly step of editing the .config
is added, with vi or sed.
This also opens a chicken-and-egg problem... What kind of config is
generated by allmodconfig when ARCH==x86? There is no good answer.
The existing tradition of switching between 32-bit and 64-bit was quite
nice, and it was done in The Obvious Way(tm) -- via the method for
specifying the architecture/platform. Switching to Kconfig for that
decision is a step backwards in usability and IMO violates the Principle
of Least Surprise.
Jeff
On Sat, Nov 03, 2007 at 10:02:19PM -0400, Jeff Garzik wrote:
> Sam Ravnborg wrote:
>> This patchset unify the i386 and x86_64 Kconfig
>> files for x86.
>> In addition it replaces the use of ARCH=i386 and
>> ARCH=x86_64 with the more intuitive ARCH=x86.
>> The primary purpose of this patch serie is to enable make ARCH=x86 and let
>> the config decide
>> if we are building for 32 or 64 bit.
>
> Yuck, I dislike. Please don't take away this nice development workflow.
> the current workflow of
>
> make ARCH=i386 allmodconfig && make ARCH=i386 -sj5
>
> no longer works. Now, the new and ungainly step of editing the .config is
> added, with vi or sed.
You could say the same about allmodconfig and 32bit on powerpc.
Or about allmodconfig and 64bit on mips.
Or about allmodconfig and little endian on mips.
Or about allmodconfig and drivers depending on !SMP on x86.
...
> This also opens a chicken-and-egg problem... What kind of config is
> generated by allmodconfig when ARCH==x86? There is no good answer.
This option won't be different from all the other similar options
allmodconfig already handles in a non-random way...
> The existing tradition of switching between 32-bit and 64-bit was quite
> nice, and it was done in The Obvious Way(tm) -- via the method for
> specifying the architecture/platform. Switching to Kconfig for that
> decision is a step backwards in usability and IMO violates the Principle of
> Least Surprise.
The existing tradition on the powerpc and mips ports that have 32bit and
64bit together in one directory is to switch in Kconfig, and doing it
differently in the x86 port would violate the Principle of the Least
Surprise.
> 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
Jeff Garzik wrote:
> This also opens a chicken-and-egg problem... What kind of config is
> generated by allmodconfig when ARCH==x86? There is no good answer.
With a unified x86 architecture, the decision to compile with 32 or
64-bit mode isn't really different from SMP vs UP, PAE vs non-PAE and so
on. It's just a config option with global effects. Over time, the
number of config options with are really 32 or 64-bit specific will
probably pretty small.
> The existing tradition of switching between 32-bit and 64-bit was
> quite nice, and it was done in The Obvious Way(tm) -- via the method
> for specifying the architecture/platform. Switching to Kconfig for
> that decision is a step backwards in usability and IMO violates the
> Principle of Least Surprise.
The architecture is now x86, with a further 32 or 64-bit parameter. We
already have config options for setting the sub-architecture.
J
On Sun, Nov 04, 2007 at 12:48:26AM +0100, Sam Ravnborg wrote:
> This patchset unify the i386 and x86_64 Kconfig
> files for x86.
> In addition it replaces the use of ARCH=i386 and
> ARCH=x86_64 with the more intuitive ARCH=x86.
>
> The primary purpose of this patch serie is to
> enable make ARCH=x86 and let the config decide
> if we are building for 32 or 64 bit.
Nice! Thanks a lot for the work.
> But we will break quite a high number of
> scripts with this change.
> What is the desired behaviour when specifying:
> make ARCH=i386
> and
> make ARCH=x86_64
> ??
>
> For now it just error out like this:
> $ make ARCH=i386
> Makefile:503: /home/sam/kernel/x86.git/arch/i386/Makefile: No such file or directory
> make: *** No rule to make target `/home/sam/kernel/x86.git/arch/i386/Makefile'. Stop.
Sounds fine, other architectures had that exactly same issue before. Maybe
we can add a more useful message thouigh like
$ARCH does not exist for any non-existant arch.
> >
> > For now it just error out like this:
> > $ make ARCH=i386
> > Makefile:503: /home/sam/kernel/x86.git/arch/i386/Makefile: No such file or directory
> > make: *** No rule to make target `/home/sam/kernel/x86.git/arch/i386/Makefile'. Stop.
>
> Sounds fine, other architectures had that exactly same issue before. Maybe
> we can add a more useful message thouigh like
>
> $ARCH does not exist for any non-existant arch.
Like this:
$ make ARCH=foo
Makefile:201: *** "ERROR: ARCH (foo) does not exist". Stop.
Implemented by following patch.
Sam
diff --git a/Makefile b/Makefile
index cd8701e..9c46a70 100644
--- a/Makefile
+++ b/Makefile
@@ -196,6 +196,11 @@ CROSS_COMPILE ?=
UTS_MACHINE := $(ARCH)
SRCARCH := $(ARCH)
+# Sanity check the specified ARCH
+ifeq ($(wildcard $(srctree)/arch/$(SRCARCH)),)
+ $(error "ERROR: ARCH ($(SRCARCH)) does not exist")
+endif
+
KCONFIG_CONFIG ?= .config
# SHELL used by kbuild
> Like this:
> $ make ARCH=foo
> Makefile:201: *** "ERROR: ARCH (foo) does not exist". Stop.
Seems sane, but maybe it would be worth putting in a special case
check for someone using i386 or x86_64 for ARCH, and tell them to
switch to x86?
- R.
On Mon, Nov 05, 2007 at 01:36:42PM -0800, Roland Dreier wrote:
> > Like this:
> > $ make ARCH=foo
> > Makefile:201: *** "ERROR: ARCH (foo) does not exist". Stop.
>
> Seems sane, but maybe it would be worth putting in a special case
> check for someone using i386 or x86_64 for ARCH, and tell them to
> switch to x86?
Will do so if my patchset gets applied. Need to redo it but
that will be later this week and then I hope for a bit more
feedback from the x86 guys.
Sam
Sam Ravnborg wrote:
> On Mon, Nov 05, 2007 at 01:36:42PM -0800, Roland Dreier wrote:
>> > Like this:
>> > $ make ARCH=foo
>> > Makefile:201: *** "ERROR: ARCH (foo) does not exist". Stop.
>>
>> Seems sane, but maybe it would be worth putting in a special case
>> check for someone using i386 or x86_64 for ARCH, and tell them to
>> switch to x86?
>
> Will do so if my patchset gets applied. Need to redo it but
> that will be later this week and then I hope for a bit more
> feedback from the x86 guys.
The patchset has looked good to me, and I believe it would be better to
take this particular breakage sooner rather than later.
I haven't spoken up actively mostly because I wanted to look at the user
comments as they have been coming in.
The issue with "make allyesconfig" concerns me, although the same
situation already exists with any multiple-choice configuration. What I
guess we really want is to be able to specify a few specific choices.
-hpa
On 11/6/07, H. Peter Anvin <[email protected]> wrote:
> The issue with "make allyesconfig" concerns me, although the same
> situation already exists with any multiple-choice configuration. What I
> guess we really want is to be able to specify a few specific choices.
I don't know enough about Kbuild to know if it's possible or not, but I
would find it great if the *config targets could take CONFIG_ variables
on the command line, like:
make oldconfig CONFIG_SMP=y
If it's not possible, why not inherit the CONFIG_ options from environment
variables, like we already do for $CFLAGS, but only at make *config
time in this case?
--
Guillaume
Guillaume Chazarain wrote:
> On 11/6/07, H. Peter Anvin <[email protected]> wrote:
>> The issue with "make allyesconfig" concerns me, although the same
>> situation already exists with any multiple-choice configuration. What I
>> guess we really want is to be able to specify a few specific choices.
>
> I don't know enough about Kbuild to know if it's possible or not, but I
> would find it great if the *config targets could take CONFIG_ variables
> on the command line, like:
>
> make oldconfig CONFIG_SMP=y
>
> If it's not possible, why not inherit the CONFIG_ options from environment
> variables, like we already do for $CFLAGS, but only at make *config
> time in this case?
>
It probably can only be done at *config time (and probably *should* only
be done at *config time); but it seems like it would be a
straightforward addition to Kconfig to look in the environment for
variables named CONFIG_* just like it'd look in an old config file.
That would definitely resolve a lot of issues.
-hpa
On Mon, Nov 05, 2007 at 03:46:20PM -0800, H. Peter Anvin wrote:
> Sam Ravnborg wrote:
>> On Mon, Nov 05, 2007 at 01:36:42PM -0800, Roland Dreier wrote:
>>> > Like this:
>>> > $ make ARCH=foo
>>> > Makefile:201: *** "ERROR: ARCH (foo) does not exist". Stop.
>>>
>>> Seems sane, but maybe it would be worth putting in a special case
>>> check for someone using i386 or x86_64 for ARCH, and tell them to
>>> switch to x86?
>>
>> Will do so if my patchset gets applied. Need to redo it but
>> that will be later this week and then I hope for a bit more
>> feedback from the x86 guys.
>
> The patchset has looked good to me, and I believe it would be better to
> take this particular breakage sooner rather than later.
>
> I haven't spoken up actively mostly because I wanted to look at the user
> comments as they have been coming in.
>
> The issue with "make allyesconfig" concerns me, although the same situation
> already exists with any multiple-choice configuration. What I guess we
> really want is to be able to specify a few specific choices.
It's already available:
$ cat myconfig
CONFIG_HIGHMEM64G=y
CONFIG_SMP=n
CONFIG_PCI=n
CONFIG_IPV6=m
$ make allyesconfig KCONFIG_ALLCONFIG=myconfig
> -hpa
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
Adrian Bunk wrote:
>>
>> The issue with "make allyesconfig" concerns me, although the same situation
>> already exists with any multiple-choice configuration. What I guess we
>> really want is to be able to specify a few specific choices.
>
> It's already available:
>
> $ cat myconfig
> CONFIG_HIGHMEM64G=y
> CONFIG_SMP=n
> CONFIG_PCI=n
> CONFIG_IPV6=m
> $ make allyesconfig KCONFIG_ALLCONFIG=myconfig
>
OK. It would be nicer to be able to specify things via variables
directly on the command line, but definitely fills the need.
-hpa