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

On 16/07/2026 18.40, Thomas Weißschuh wrote:
> Hi Thomas,
> 
> On 2026-07-16 12:24:07+0200, Thomas Huth wrote:
>> On 09/03/2026 16.58, Thomas Weißschuh wrote:
>>> There is an ongoing effort to replace the usage of __ASSEMBLER__ with
>>> __ASSEMBLY__ throughout the kernel tree, see for example
>>> commit 287d163322b7 ("arm64: Replace __ASSEMBLY__ with __ASSEMBLER__ in
>>> non-uapi headers"). The latter is automatically provided by all compilers
>>> and preprocessors supported by the kernel, so the explicit definitions
>>> of __ASSEMBLER__ can be removed.
>>>
>>> However the UAPI headers might be used with older (< GCC 3.0) or
>>> non-GCC-compatible compilers, which do not define __ASSEMBLY__
>>> automatically.
>>
>> I just had a try with gcc 2.95.4 from a Debian Woody installation, and it
>> defines __ASSEMBLER__ automatically when compiling *.S files, i.e. gcc 2.95
>> does not seem to be a problem. So can you point me to a real case where
>> someone tried to use a user space compiler where __ASSEMBLER__ was not
>> defined automatically? Otherwise, I think this patch could be reverted
>> again.
> 
> I don't have a specific case I can point you to. My goal was
> consistency. Therefore I am against reverting the patch as long as
> both __ASSEMBLER__ and __ASSEMBLY__ are used in the UAPI headers.

I've got patches for all files ready and posted them a couple of times 
already - the problem is, some maintainers are not responsive / ignoring me 
... so I'm afraid but I guess we'll be in this inconsistent state for a 
little bit longer...

> If we want to switch to __ASSEMBLER__ for the UAPI headers today,
> we should instead invert the logic of this patch to consistently use it
> everywhere. After all UAPI headers are migrated, the normalization can
> then be removed.
That sounds like the better idea to me. Could you maybe send a patch, or 
want me to do it?

  Thanks,
   Thomas