Re: [PATCH] s390/uapi: Replace __ASSEMBLY__ with __ASSEMBLER__ in uapi headers

[Thomas Huth]

On 10/03/2025 12.07, Arnd Bergmann wrote:
> On Mon, Mar 10, 2025, at 11:49, Heiko Carstens wrote:
> > On Mon, Mar 10, 2025 at 11:26:57AM +0100, Thomas Huth wrote:
> >
> > Did this cause any sorts of problems? I can see this pattern all over
> > the place, so why is this now a problem?
> >
> > Also, wouldn't it be better to fix this with an sed statement in
> > scripts/headers_install.sh instead? Otherwise this is going to be a
> > never ending story since those things will be re-introduced all the
> > time.
>
> It should certainly be done in a consistent way across all
> architectures and architecture-independent headers. I see that
> all uapi headers use __ASSEMBLY__ consistently, while a few non-uapi
> headers use __ASSEMBLER__.
>
> glibc obviously defines __ASSEMBLY__ whenever it includes one
> of the kernel headers that need this from a .S file. Unless
> there is a known problem with the current code, leaving this
> unchanged is probably the least risky way.

Well, this seems to be constant source of confusion. It got my attention by 
Sean's recent patch for kvm-unit-tests here:

 https://lore.kernel.org/kvm/20250222014526.2302653-1-seanjc@xxxxxxxxxx/

Quoting: "This is essentially a "rage" patch after spending
way, way too much time trying to understand why I couldn't include some
__ASSEMBLY__ protected headers in x86 assembly files."

But also if you search the net for this, there are lots of other spots where 
people get it wrong, e.g.:

 https://stackoverflow.com/questions/28924355/gcc-assembler-preprocessor-not-compatible-with-standard-headers
 https://forums.raspberrypi.com/viewtopic.php?p=1652944#p1653834
 https://github.com/riscv-software-src/opensbi/issues/199

So I thought it would be a good idea to standardize on the #define that is 
set by the compiler already. IMHO it would be great to get it replaced in 
the whole kernel, but that's a little bit bold for one patch. So the obvious 
first step towards that direction is to replace it in the uapi header files 
first, where it hopefully will help to reduce the confusion in userspace. 
So unless you really don't like this idea at all, I could continue with the 
uapi headers for the other architectures, too?

 Thomas