scripts/headers_install.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
From: Thomas Huth <thuth@redhat.com>
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 <linux@weissschuh.net>
Link: https://lore.kernel.org/all/2030a963-33bc-43fe-9a2b-9c626d7d8360@redhat.com/
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
Based-on: https://lore.kernel.org/all/20260630-uapi-assembly-v2-1-8e7bee2fe816@weissschuh.net/
To avoid the churn, feel free to squash this patch with
Thomas Weißschuh's original patch as long as it has not been
merged to Linus' tree yet.
scripts/headers_install.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/headers_install.sh b/scripts/headers_install.sh
index 83e4475968781..2f1d1767ca267 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
--
2.55.0
On 2026-07-20 12:10:25+0200, Thomas Huth wrote: > From: Thomas Huth <thuth@redhat.com> > > 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. I am not that happy about this explanation. The note about old GCC was dropped in the committed version of the patch. It should be enough to just explain why __ASSEMBLER__ is better. > Thus let's head forwards and standardize on __ASSEMBLER__ instead > of __ASSEMBLY__ in the UAPI header files now. > > Suggested-by: Thomas Weißschuh <linux@weissschuh.net> > Link: https://lore.kernel.org/all/2030a963-33bc-43fe-9a2b-9c626d7d8360@redhat.com/ > Signed-off-by: Thomas Huth <thuth@redhat.com> > --- > Based-on: https://lore.kernel.org/all/20260630-uapi-assembly-v2-1-8e7bee2fe816@weissschuh.net/ > > To avoid the churn, feel free to squash this patch with > Thomas Weißschuh's original patch as long as it has not been > merged to Linus' tree yet. > > scripts/headers_install.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/headers_install.sh b/scripts/headers_install.sh > index 83e4475968781..2f1d1767ca267 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 > -- > 2.55.0 >
On 21/07/2026 23.32, Thomas Weißschuh wrote: > On 2026-07-20 12:10:25+0200, Thomas Huth wrote: >> From: Thomas Huth <thuth@redhat.com> >> >> 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. > > I am not that happy about this explanation. The note about old GCC was > dropped in the committed version of the patch. > It should be enough to just explain why __ASSEMBLER__ is better. Ok, I sent a v2 with an updated patch description, I hope that's better: https://lore.kernel.org/lkml/20260722072928.24500-1-thuth@redhat.com/ If not, please provide a suggestion how it should look like. Thanks, Thomas PS: Nicolas, I kept your Reviewed-by in v2 ... if you disagree with the updated patch description, please complain there!
> 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 <linux@weissschuh.net> > Link: https://lore.kernel.org/all/2030a963-33bc-43fe-9a2b-9c626d7d8360@redhat.com/ > Signed-off-by: Thomas Huth <thuth@redhat.com> > > 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 <n.schier@fritz.com> Tested-by: Nicolas Schier <n.schier@fritz.com> 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
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 <linux@weissschuh.net> > > Link: https://lore.kernel.org/all/2030a963-33bc-43fe-9a2b-9c626d7d8360@redhat.com/ > > Signed-off-by: Thomas Huth <thuth@redhat.com> > > > > 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 <n.schier@fritz.com> > Tested-by: Nicolas Schier <n.schier@fritz.com> > > 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
© 2016 - 2026 Red Hat, Inc.