Re: [PATCH v2] arm: Replace ASSEMBLY with ASSEMBLER in uapi headers

[Thomas Weißschuh]

On 2026-03-01 20:12:11+0000, Maciej W. Rozycki wrote:
> On Sat, 28 Feb 2026, Nick Huang wrote:
> 
> > > But as most other architecture UAPI headers already have switched to
> > > __ASSEMBLER__, it seems nobody will be affected by this, so this check
> > > should be unnecessary.
> 
>  It seems to whom?  Have you got a reference to a discussion with libc 
> maintainers where the consensus has been that support for older compilers 
> can be dropped?  Why does it remain in the GNU C library?

To me, based on the fact that nobody has complained so far about the
other architectures. But I don't really want to advocate for dropping
compatibility.

> > I'm aware that other architectures have transitioned to __ASSEMBLER__.
> > However, I implemented this check here because Maciej W. Rozycki
> > specifically suggested this approach during our discussion.
> 
>  I asked a question whether this is relevant.  The outcome could well be 
> that it is not, but with data available at hand such a conclusion cannot 
> be made in my opinion.

Fair enough. I have no issues with retaining the compatibility.
But the approach in this patch is counterproductive to compatibility.
For regular C sources, which I assume are most users of the UAPI
headers, the __ASSEMBLER__ or __ASSEMBLY__ are wholly irrelevant.
But with this patch they will be hard broken. Also UAPI consumers which
might be perfectly happy to manually define __ASSEMBLY__ will now run
into a hard error. So this check is strictly *less* compatible with
exactly those old compilers.

Given that there is a general switch to __ASSEMBLY__ for regular kernel
headers, the chances are high that adding these manual version checks to
the UAPI headers will be forgotten frequently and will require a lot of
fixups. If we want to stay compatible, we should do the following:

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


Then we can convert all UAPI headers to the in-kernel style using
__ASSEMBLY__ and drop -DASSEMBLER from kbuild. Userspace will still
work as before and if we come to the point to drop compatibility,
we can do so far all UAPI headers at the same time, without any
inconsistencies.

Right now I think the consistency argument is enough that this should
have been done from the beginning. Your thoughts?


Thomas