linux-kernel - Re: [PATCH 04/15] x86/kbuild: Introduce the 'x86

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 for Android: free password hash cracker in your pocket

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

Message-Id: <cd541739-4ec5-4772-9cef-e3527fc69e26@app.fastmail.com>
Date: Wed, 07 May 2025 07:44:06 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Ingo Molnar" <mingo@...nel.org>, linux-kernel@...r.kernel.org
Cc: "H. Peter Anvin" <hpa@...or.com>,
 "Linus Torvalds" <torvalds@...ux-foundation.org>,
 "Peter Zijlstra" <peterz@...radead.org>, "Borislav Petkov" <bp@...en8.de>,
 "Thomas Gleixner" <tglx@...utronix.de>,
 "Vitaly Kuznetsov" <vkuznets@...hat.com>, "Ard Biesheuvel" <ardb@...nel.org>,
 "David Woodhouse" <dwmw@...zon.co.uk>,
 "Masahiro Yamada" <yamada.masahiro@...ionext.com>,
 "Michal Marek" <michal.lkml@...kovi.net>
Subject: Re: [PATCH 04/15] x86/kbuild: Introduce the 'x86_32' subarchitecture

On Tue, May 6, 2025, at 19:09, Ingo Molnar wrote:
> 
>  # Additional ARCH settings for x86
> -ifeq ($(ARCH),i386)
> +ifeq ($(ARCH),x86_64)
>          SRCARCH := x86
>  endif
> -ifeq ($(ARCH),x86_64)
> +ifeq ($(ARCH),x86_32)
> +        SRCARCH := x86
> +endif
> +ifeq ($(ARCH),i386)
>          SRCARCH := x86
>  endif

Would it be possible to just remove the entire SRCARCH hack
for x86? It's not clear from the changelog what the intention
was in 2007 when it was added, but my impression was that
this should be a temporary workaround to users doing
'make defconfig' on i386 would still get a 32-bit config
by default and didn't have to change there scripts.

I would guess that even in a 'setarch --32bit' environment,
most users today would want to build a 64-bit kernel, having
the special case for that seems to add more confusion that
it avoids.

Also, I don't think there are any systems that return
'x86_32' from 'uname -m', so your added special case
would never be used by default, only when cross-compiling
from some other architecture.

      Arnd