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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ