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

On Tue, Jul 21, 2026 at 01:14:55PM +0200, Nicolas Schier wrote:
> > 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.

Given the additional information provided in this commit message, I
think it is fine to keep them separate, even aside from the regressions
concern.

-- 
Cheers,
Nathan