There is an ongoing effort to replace the usage of __ASSEMBLER__ with
__ASSEMBLY__ throughout the kernel tree, see for example
commit 287d163322b7 ("arm64: Replace __ASSEMBLY__ with __ASSEMBLER__ in
non-uapi headers"). The latter is automatically provided by all compilers
and preprocessors supported by the kernel, so the explicit definitions
of __ASSEMBLER__ can be removed.

However the UAPI headers might be used with older (< GCC 3.0) or
non-GCC-compatible compilers, which do not define __ASSEMBLY__
automatically. So this migration may brake users.
Also during the migration phase, the UAPI headers will use a mix of
*both* __ASSEMBLY__ and __ASSEMBLER__ at the same time, which is ugly.

For now make sure that the exported UAPI headers consistently use
__ASSEMBLER__ as before.

Link: https://lore.kernel.org/lkml/164baf81-2824-4943-bbc1-4ae8a160c0cc@t-8ch.de/
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
This should go either through kbuild or asm-generic, I think.
---
 scripts/headers_install.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/headers_install.sh b/scripts/headers_install.sh
index 9c15e748761c..2f1d1767ca26 100755
--- a/scripts/headers_install.sh
+++ b/scripts/headers_install.sh
@@ -36,6 +36,7 @@ sed -E -e '
 	s/(^|[^a-zA-Z0-9])__packed([^a-zA-Z0-9_]|$)/\1__attribute__((packed))\2/g
 	s/(^|[[:space:](])(inline|asm|volatile)([[:space:](]|$)/\1__\2__\3/g
 	s@#(ifndef|define|endif[[:space:]]*/[*])[[:space:]]*_UAPI@#\1 @
+	s/__ASSEMBLY__/__ASSEMBLER__/g
 ' $INFILE > $TMPFILE || exit 1
 
 scripts/unifdef -U__KERNEL__ -D__EXPORTED_HEADERS__ $TMPFILE > $OUTFILE

---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260302-uapi-assembly-0bb7213b41f1

Best regards,
-- 
Thomas Weißschuh <linux@weissschuh.net>

On Mon, Mar 09, 2026 at 04:58:11PM +0100, Thomas Weißschuh wrote:
> There is an ongoing effort to replace the usage of __ASSEMBLER__ with
> __ASSEMBLY__ throughout the kernel tree, see for example

I think __ASSEMBLER__ and __ASSEMBLY__ are swapped here?

> commit 287d163322b7 ("arm64: Replace __ASSEMBLY__ with __ASSEMBLER__ in
> non-uapi headers"). The latter is automatically provided by all compilers
> and preprocessors supported by the kernel, so the explicit definitions
> of __ASSEMBLER__ can be removed.
> 
> However the UAPI headers might be used with older (< GCC 3.0) or
> non-GCC-compatible compilers, which do not define __ASSEMBLY__

__ASSEMBLER__?

> automatically. So this migration may brake users.

It sounds like the "< GCC 3.0" part of that might not be true based on
Maciej's research?

  https://lore.kernel.org/alpine.DEB.2.21.2603101412520.63708@angie.orcam.me.uk/

> Also during the migration phase, the UAPI headers will use a mix of
> *both* __ASSEMBLY__ and __ASSEMBLER__ at the same time, which is ugly.
> 
> For now make sure that the exported UAPI headers consistently use
> __ASSEMBLER__ as before.

__ASSEMBLY__?

> Link: https://lore.kernel.org/lkml/164baf81-2824-4943-bbc1-4ae8a160c0cc@t-8ch.de/
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> This should go either through kbuild or asm-generic, I think.
> ---
>  scripts/headers_install.sh | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/scripts/headers_install.sh b/scripts/headers_install.sh
> index 9c15e748761c..2f1d1767ca26 100755
> --- a/scripts/headers_install.sh
> +++ b/scripts/headers_install.sh
> @@ -36,6 +36,7 @@ sed -E -e '
>  	s/(^|[^a-zA-Z0-9])__packed([^a-zA-Z0-9_]|$)/\1__attribute__((packed))\2/g
>  	s/(^|[[:space:](])(inline|asm|volatile)([[:space:](]|$)/\1__\2__\3/g
>  	s@#(ifndef|define|endif[[:space:]]*/[*])[[:space:]]*_UAPI@#\1 @
> +	s/__ASSEMBLY__/__ASSEMBLER__/g

It seems like this does the opposite of what is intended or am I
misunderstanding something here?

>  ' $INFILE > $TMPFILE || exit 1
>  
>  scripts/unifdef -U__KERNEL__ -D__EXPORTED_HEADERS__ $TMPFILE > $OUTFILE
> 
> ---
> base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
> change-id: 20260302-uapi-assembly-0bb7213b41f1
> 
> Best regards,
> -- 
> Thomas Weißschuh <linux@weissschuh.net>
> 

Hi Nathan,

sorry for the late response, this seems to have fallen through the
cracks.

On 2026-03-13 16:56:18-0700, Nathan Chancellor wrote:
> On Mon, Mar 09, 2026 at 04:58:11PM +0100, Thomas Weißschuh wrote:
> > There is an ongoing effort to replace the usage of __ASSEMBLER__ with
> > __ASSEMBLY__ throughout the kernel tree, see for example
> 
> I think __ASSEMBLER__ and __ASSEMBLY__ are swapped here?

Indeed.

(Also all the other cases)

(...)

> > automatically. So this migration may brake users.
> 
> It sounds like the "< GCC 3.0" part of that might not be true based on
> Maciej's research?
> 
>   https://lore.kernel.org/alpine.DEB.2.21.2603101412520.63708@angie.orcam.me.uk/

Yes, indeed. In my opinion the consistency aspect is still sufficient
to have this change. What do you think?

(...)


Thomas

On Tue, Mar 24, 2026 at 06:05:34PM +0100, Thomas Weißschuh wrote:
> On 2026-03-13 16:56:18-0700, Nathan Chancellor wrote:
> > It sounds like the "< GCC 3.0" part of that might not be true based on
> > Maciej's research?
> > 
> >   https://lore.kernel.org/alpine.DEB.2.21.2603101412520.63708@angie.orcam.me.uk/
> 
> Yes, indeed. In my opinion the consistency aspect is still sufficient
> to have this change. What do you think?

Yes, I think so. Will you keep it as going from __ASSEMBLY__ to
__ASSEMBLER__? It probably makes more sense that way given there should
be no regressions on the compiler side and that is the intended end
result?

Cheers,
Nathan

On 2026-03-24 11:35:01-0700, Nathan Chancellor wrote:
> On Tue, Mar 24, 2026 at 06:05:34PM +0100, Thomas Weißschuh wrote:
> > On 2026-03-13 16:56:18-0700, Nathan Chancellor wrote:
> > > It sounds like the "< GCC 3.0" part of that might not be true based on
> > > Maciej's research?
> > > 
> > >   https://lore.kernel.org/alpine.DEB.2.21.2603101412520.63708@angie.orcam.me.uk/
> > 
> > Yes, indeed. In my opinion the consistency aspect is still sufficient
> > to have this change. What do you think?
> 
> Yes, I think so. Will you keep it as going from __ASSEMBLY__ to
> __ASSEMBLER__? It probably makes more sense that way given there should
> be no regressions on the compiler side and that is the intended end
> result?

I would have stuck to the old name '__ASSEMBLY__', just for robustness
and because we are late in the cycle.
Then we can switch it early in the next cycle.


Thomas