linux-kernel - Re: [PATCH v2 0/2] m68k: Replace __ASSEMBLY__ with __ASSEMBLER_

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] [day] [month] [year] [list]

Message-ID: <CAMuHMdWGQfHJMFydTWE=adavrzeoSdzP_n2ht_Co96z_7M6GwQ@mail.gmail.com>
Date: Sun, 6 Jul 2025 11:39:39 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Thomas Huth <thuth@...hat.com>
Cc: linux-m68k@...ts.linux-m68k.org, Greg Ungerer <gerg@...ux-m68k.org>, 
	Sam Creasey <sammy@...my.net>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/2] m68k: Replace __ASSEMBLY__ with __ASSEMBLER__ in
 uapi headers

On Wed, 11 Jun 2025 at 13:41, Thomas Huth <thuth@...hat.com> wrote:
> The kernel Makefiles define the __ASSEMBLY__ macro to provide
> a way to use headers in both, assembly and C source code.
> However, all the supported versions of the GCC and Clang compilers
> also define the macro __ASSEMBLER__ automatically already when compiling
> assembly code, so some kernel headers are using __ASSEMBLER__ instead.
> With regards to userspace code, this seems also to be constant source
> of confusion, see for example these links here:
>
>  https://lore.kernel.org/kvm/20250222014526.2302653-1-seanjc@google.com/
>  https://stackoverflow.com/questions/28924355/gcc-assembler-preprocessor-not-compatible-with-standard-headers
>  https://forums.raspberrypi.com/viewtopic.php?p=1652944#p1653834
>  https://github.com/riscv-software-src/opensbi/issues/199
>
> To avoid confusion in the future, it would make sense to standardize
> on the macro that gets defined by the compiler, so this patch series
> changes all occurances of __ASSEMBLY__ into __ASSEMBLER__.
>
> I split the patches per architecture to ease the review, and I also
> split the uapi headers from the normal ones in case we decide that
> uapi needs to be treated differently from the normal headers here.
>
> The x86, parisc and sh patches already got merged via their specific
> architecture tree:
>
>  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=24a295e4ef1ca8
>  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8a141be3233af7
>  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cccaea1d66e94b
>  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e2b6a188625a2b
>  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9cc646950eefda
>
> So I assume the m68k patches should go via the m68k tree.
>
> v2:
> - Split the m68k patches from the global series
>   (see https://lore.kernel.org/all/20250314071013.1575167-1-thuth@redhat.com/)
> - Rebased the patches on linux-next and fixed the conflicts
>   and new occurances of __ASSEMBLY__
>
> Thomas Huth (2):
>   m68k: Replace __ASSEMBLY__ with __ASSEMBLER__ in uapi headers
>   m68k: Replace __ASSEMBLY__ with __ASSEMBLER__ in non-uapi headers

Reviewed-by: Geert Uytterhoeven <geert@...ux-m68k.org>
i.e. will queue in the m68k tree for v6.17.

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds