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
| ||
|
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
Powered by blists - more mailing lists