lkml.org 
[lkml]   [2011]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3] x86, kconfig: Default to ARCH=x86 to avoid overriding CONFIG_64BIT
From
Date
On Sat, 2011-07-30 at 18:21 -0400, Arnaud Lacombe wrote:
> > I'll work on a patch to fix that, and then it will be fine when the
> > default for SUBARCH changes to be "x86".
> >
> I still fail to see why you want it that way... You want both ARCH and
> SUBARCH to be 'x86' ?

See the way that SUBARCH is inferred in the Makefile, and then ARCH is
set to match it (unless ARCH is set by the user).

To change the default setting of ARCH, we actually change the inference
of *SUBARCH*. And yes, in the common case they are both the *same*; the
SUBARCH variable doesn't really do anything except work as a temporary
variable holding the default setting for ARCH.

In an ARCH=um build, of course they *are* different, and SUBARCH is
actually used for more than that.

> This starts to be a hell lots of deep changes just to fix i386 build
> under a fast x86-64 without having to specify ARCH=i386. That job
> alone can be done a lot easier.

It's not just that. It's also about making things work properly as
config options — so we can finally complete the merge of arch/i386 and
arch/x86_64, which directories we deleted almost four years ago, into
the single 'x86' architecture.

After a few 'unrelated' cleanups to how $(SUBARCH) is handled, the patch
to make SUBARCH=x86 work in um really isn't that intrusive at all; I'll
post the sequence shortly.

We *could* preserve the legacy inference of SUBARCH={i386,x86_64} *just*
for the ARCH=um case, but I think it's better not to.

--
dwmw2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2011-07-31 01:01    [W:0.121 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site