Cc: Jeff Garzik <jeff@...>, Paul Mundt <lethal@...>, Thomas Gleixner <tglx@...>, Ingo Molnar <mingo@...>, H. Peter Anvin <hpa@...>, LKML <linux-kernel@...>, Linus Torvalds <torvalds@...>, Andrew Morton <akpm@...>
as a user I think it would be a good idea to keep the i386/x86_64 options
around for a few kernel revisions to maintain compatibilty with people's
build scripts (not everyone upgrades every kernel release. I've been
running kernel.org kernels in production for over 10 years and between the
scheduler changes in .23 and the arch merge in .24 even I'm going to be
very cautious until .25 or .26 fleshes out all the gotchas, although the
per-device buffer work is valuble enough that a couple systems will get
it soon)
you also need a transition for make oldconfig for several versions
i386 should imply 32 bit and the old CPU i386 options
x86_64 should imply 64 bit and the old amd_64 cpu options
unknown, which cpu did you select to compile it for? and in the case of
cpus that support both modes, which one did you select? I don't know if
it makes sense to just list K8-32 and K8-64 as seperate cpu options in one
menu or to have a 32/64 bit switch and then two seperate cpu menus (I
suspect the first is better in the long run) but either way can work.
why do you need to have it as a specific command-line option instead of
being part of your cpu selection?
and isn't there something like march=686 that could be extended to
march=k8-32 vs march=k8-64?
march=s390-64 or s390-32 doesn't look nearly as bad as s39064 that you
listed above.
David Lang
-
