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: <CACqU3MXak0Yo+VDQNEqT9rTJ5CjdU6jJ-C1Km7GauMQ+qGW+vg@mail.gmail.com>
Date:	Sun, 31 Jul 2011 18:07:55 -0400
From:	Arnaud Lacombe <lacombar@...il.com>
To:	David Woodhouse <dwmw2@...radead.org>
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

Hi,

On Sun, Jul 31, 2011 at 4:20 PM, David Woodhouse <dwmw2@...radead.org> wrote:
> 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).
>
Irrelevant. This can still be done explicitly:

% make ARCH=arm defconfig
[... time passes ...]
% make ARCH=i386 oldconfig

> 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.
>
no. The relation between the target architecture and bitness' width is
not a bijection, and treating it as such is short-sighted.

> 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.
>
I think you totally miss the point of the patch as you keep being
self-centered on x86.

I am working with configuration for mips, sh, powerpc, arm and x86.
Some of them are for real board, some of them are to regress-test
compilers, binutils and kernel builds. Each of those config hardcode
the CROSS_COMPILER string and have their own build directory. In each
case, I want to be able to just run "make O=/src/obj/v3.0-arm
oldnoconfig all" without having to worry about anything else.
--
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/