Re: [PATCH] scripts: headers_install.sh: Normalize __ASSEMBLY__ to __ASSEMBLER__
Nicolas Schier <[email protected]> Tue, 21 Jul 2026 13:14:55 +0200
| Newsgroups | gmane.linux.kernel,gmane.linux.kbuild.devel |
|---|---|
| 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