Re: [PATCH v2] mips: Replace __ASSEMBLY__ with __ASSEMBLER__ in the mips headers

[Thomas Huth <thuth@redhat.com>]

On 04/08/2025 01.59, Maciej W. Rozycki wrote:
> On Wed, 11 Jun 2025, Thomas Huth wrote:
> 
>> While the GCC and Clang compilers already define __ASSEMBLER__
>> automatically when compiling assembler code, __ASSEMBLY__ is a
>> macro that only gets defined by the Makefiles in the kernel.
> 
>   It could be worth noting that our arrangement for the __ASSEMBLY__ macro
> obviously predates GCC's predefinition (which was only added back in 2000
> with GCC commit f8f769ea4e69, 9 years into the existence of Linux, which
> ultimately landed as GCC 3.0 release) and the whole existence of Clang.
> So the choice was perfectly fine back when it was originally made.

That's valuable information, thanks for looking that up!

>> This is bad since macros starting with two underscores are names
>> that are reserved by the C language.
> 
>   I think it's correct usage given that we're the C language environment
> here, just as any C library is.  Such names are not to be used by user
> programs and we're not one.

I just added that sentence after I've recently been told that it's rather 
the other way round:

  https://lore.kernel.org/linuxppc-dev/20250610200028.GE30295@gate.crashing.org/

I guess it's mainly a matter of opinion how to classify the kernel here?
Anyway, I can simply drop that sentence again from the description, that's 
fine for me.

>> It can also be very confusing
>> for the developers when switching between userspace and kernelspace
>> coding, or when dealing with uapi headers that rather should use
>> __ASSEMBLER__  instead. So let's now standardize on the __ASSEMBLER__
>> macro that is provided by the compilers.
> 
>   I think it's the right choice in 2025 (and would have been a few years
> earlier, for a liberal definition of "few", when we switched away from
> supporting GCC 2.95.x), so:
> 
> Reviewed-by: Maciej W. Rozycki <macro@orcam.me.uk>
> 
> for the code updates, but I think the description could have been more
> focused on how the old choice has become no longer the best one as the
> compiler evolved.
> 
>   Would you mind factoring in the observations made here?

Thanks for your review! I'll respin a v3 with an updated description.

  Thomas