Re: [PATCH] scripts: headers_install.sh: Normalize __ASSEMBLY__ to __ASSEMBLER__

Nicolas Schier <[email protected]> Tue, 21 Jul 2026 13:14:55 +0200
Newsgroups org.kernel.vger.linux-kbuild,org.kernel.vger.linux-kernel
Message-ID <178463249517.1439086.5460375188993284761.b4-review@b4>
> A previous patch to headers_install.sh normalized the usage of
> __ASSEMBLER__ to __ASSEMBLY__ in the UAPI headers due to the
> assumption that older versions of GCC might not define __ASSEMBLER__
> automatically and thus using __ASSEMBLER__ in the UAPI headers might
> break compilation with very old versions of GCC. However, as we now
> reassured, even GCC 2.95 still defines __ASSEMBLER__ automatically
> (and even older versions are hopefully not in use with the current
> Linux UAPI headers anymore).
> __ASSEMBLER__ is also set automatically by other C compilers like PCC
> (see https://github.com/IanHarvey/pcc/blob/cvs2git/2018.09.20/cc/cc/cc.1#L405)
> and Tiny-C (see https://repo.or.cz/tinycc.git/commitdiff/a25325e9be13e52a),
> so using __ASSEMBLER__ in UAPI header files should really be fine.
> 
> Thus let's head forwards and standardize on __ASSEMBLER__ instead
> of __ASSEMBLY__ in the UAPI header files now.
> 
> Suggested-by: Thomas Weißschuh <[email protected]>
> Link: https://lore.kernel.org/all/[email protected]/
> Signed-off-by: Thomas Huth <[email protected]>
>
> diff --git a/scripts/headers_install.sh b/scripts/headers_install.sh
> index 83e447596878..2f1d1767ca26 100755
> --- a/scripts/headers_install.sh
> +++ b/scripts/headers_install.sh
> @@ -36,7 +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/__ASSEMBLER__/__ASSEMBLY__/g
> +	s/__ASSEMBLY__/__ASSEMBLER__/g
>  ' $INFILE > $TMPFILE || exit 1
>  
>  scripts/unifdef -U__KERNEL__ -D__EXPORTED_HEADERS__ $TMPFILE > $OUTFILE

Thanks!

Reviewed-by: Nicolas Schier <[email protected]>
Tested-by: Nicolas Schier <[email protected]>


Even though squashing both commits sounds good to me on the first hand,
I don't want to do that right now, to simplify a possible revert in case
of reported regressions.

-- 
Nicolas