linux-kernel - Re: [PATCH] kbuild: honor the ARCH setting of the existing configuration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1312143643.12369.32.camel@i7.infradead.org>
Date:	Sun, 31 Jul 2011 21:20:42 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Aunt Tillie <lacombar@...il.com>
Cc:	Michal Marek <mmarek@...e.cz>, linux-kernel@...r.kernel.org,
	linux-kbuild@...r.kernel.org
Subject: Re: [PATCH] kbuild: honor the ARCH setting of the existing
 configuration

On Sun, 2011-07-31 at 15:44 -0400, Aunt Tillie wrote:
> This change make Kbuild honor the ARCH setting of the existing configuration, if
> any .config is present so that it does not get reset if there is a conflict
> with the default ARCH for the platform and the current setting.

I think this is the wrong approach.

There are plans to make the architecture a *real* configuration option,
and that will be lovely when it happens (and changing the 32-vs-64
distinction so that it's no longer a different ARCH but just a config
option is one step in that direction).

But I don't think this patch is really a helpful step towards that goal;
we should do that *properly* or not at all, and not give some temporary
half-baked behaviour in the meantime, that people will come to depend on
(and others will hate because it means they can't just take an ARM
config and build it on their x86 box and have it automatically
converted).

And the other problem is that this is not really addressing the
underlying issue, which is that we are still clinging to the legacy ARCH
values for directories which don't exist in the arch/ directory any
more, and which are *redundant* with the setting of CONFIG_64BIT in the
config.

The only problem here is that we're not using the merged ARCH=x86 by
default, as most of the other 64-bit capable architectures in the kernel
do — and it works just fine for all of them.

If the x86 merge still hasn't been completed, four years after we
deleted arch/{i386,x86_64}, then we need to complete it. Thanks for
helping to root out the few esoteric things that still don't quite work
right on x86; it's very useful to find them and fix them.

-- 
dwmw2

--
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/