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

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

[Thomas Weißschuh]

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. So this migration may brake users.
Also during the migration phase, the UAPI headers will use a mix of
*both* __ASSEMBLY__ and __ASSEMBLER__ at the same time, which is ugly.

For now make sure that the exported UAPI headers consistently use
__ASSEMBLER__ as before.

Link: https://lore.kernel.org/lkml/164baf81-2824-4943-bbc1-4ae8a160c0cc@t-8ch.de/
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
---
This should go either through kbuild or asm-generic, I think.
---
 scripts/headers_install.sh | 1 +
 1 file changed, 1 insertion(+)

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

---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260302-uapi-assembly-0bb7213b41f1

Best regards,
-- 
Thomas Weißschuh <linux@weissschuh.net>

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

[Nathan Chancellor]

On Mon, Mar 09, 2026 at 04:58:11PM +0100, Thomas Weißschuh wrote:
> There is an ongoing effort to replace the usage of __ASSEMBLER__ with
> __ASSEMBLY__ throughout the kernel tree, see for example

I think __ASSEMBLER__ and __ASSEMBLY__ are swapped here?

> 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__

__ASSEMBLER__?

> automatically. So this migration may brake users.

It sounds like the "< GCC 3.0" part of that might not be true based on
Maciej's research?

  https://lore.kernel.org/alpine.DEB.2.21.2603101412520.63708@angie.orcam.me.uk/

> Also during the migration phase, the UAPI headers will use a mix of
> *both* __ASSEMBLY__ and __ASSEMBLER__ at the same time, which is ugly.
> 
> For now make sure that the exported UAPI headers consistently use
> __ASSEMBLER__ as before.

__ASSEMBLY__?

> Link: https://lore.kernel.org/lkml/164baf81-2824-4943-bbc1-4ae8a160c0cc@t-8ch.de/
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> This should go either through kbuild or asm-generic, I think.
> ---
>  scripts/headers_install.sh | 1 +
>  1 file changed, 1 insertion(+)
> 
> 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

It seems like this does the opposite of what is intended or am I
misunderstanding something here?

>  ' $INFILE > $TMPFILE || exit 1
>  
>  scripts/unifdef -U__KERNEL__ -D__EXPORTED_HEADERS__ $TMPFILE > $OUTFILE
> 
> ---
> base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
> change-id: 20260302-uapi-assembly-0bb7213b41f1
> 
> Best regards,
> -- 
> Thomas Weißschuh <linux@weissschuh.net>
> 

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

[Thomas Weißschuh]

Hi Nathan,

sorry for the late response, this seems to have fallen through the
cracks.

On 2026-03-13 16:56:18-0700, Nathan Chancellor wrote:
> On Mon, Mar 09, 2026 at 04:58:11PM +0100, Thomas Weißschuh wrote:
> > There is an ongoing effort to replace the usage of __ASSEMBLER__ with
> > __ASSEMBLY__ throughout the kernel tree, see for example
> 
> I think __ASSEMBLER__ and __ASSEMBLY__ are swapped here?

Indeed.

(Also all the other cases)

(...)

> > automatically. So this migration may brake users.
> 
> It sounds like the "< GCC 3.0" part of that might not be true based on
> Maciej's research?
> 
>   https://lore.kernel.org/alpine.DEB.2.21.2603101412520.63708@angie.orcam.me.uk/

Yes, indeed. In my opinion the consistency aspect is still sufficient
to have this change. What do you think?

(...)


Thomas

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

[Nathan Chancellor]

On Tue, Mar 24, 2026 at 06:05:34PM +0100, Thomas Weißschuh wrote:
> On 2026-03-13 16:56:18-0700, Nathan Chancellor wrote:
> > It sounds like the "< GCC 3.0" part of that might not be true based on
> > Maciej's research?
> > 
> >   https://lore.kernel.org/alpine.DEB.2.21.2603101412520.63708@angie.orcam.me.uk/
> 
> Yes, indeed. In my opinion the consistency aspect is still sufficient
> to have this change. What do you think?

Yes, I think so. Will you keep it as going from __ASSEMBLY__ to
__ASSEMBLER__? It probably makes more sense that way given there should
be no regressions on the compiler side and that is the intended end
result?

Cheers,
Nathan

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

[Thomas Weißschuh]

On 2026-03-24 11:35:01-0700, Nathan Chancellor wrote:
> On Tue, Mar 24, 2026 at 06:05:34PM +0100, Thomas Weißschuh wrote:
> > On 2026-03-13 16:56:18-0700, Nathan Chancellor wrote:
> > > It sounds like the "< GCC 3.0" part of that might not be true based on
> > > Maciej's research?
> > > 
> > >   https://lore.kernel.org/alpine.DEB.2.21.2603101412520.63708@angie.orcam.me.uk/
> > 
> > Yes, indeed. In my opinion the consistency aspect is still sufficient
> > to have this change. What do you think?
> 
> Yes, I think so. Will you keep it as going from __ASSEMBLY__ to
> __ASSEMBLER__? It probably makes more sense that way given there should
> be no regressions on the compiler side and that is the intended end
> result?

I would have stuck to the old name '__ASSEMBLY__', just for robustness
and because we are late in the cycle.
Then we can switch it early in the next cycle.


Thomas

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

[Nicolas Schier]

On Tue, Mar 24, 2026 at 08:58:08PM +0100, Thomas Weißschuh wrote:
> On 2026-03-24 11:35:01-0700, Nathan Chancellor wrote:
> > On Tue, Mar 24, 2026 at 06:05:34PM +0100, Thomas Weißschuh wrote:
> > > On 2026-03-13 16:56:18-0700, Nathan Chancellor wrote:
> > > > It sounds like the "< GCC 3.0" part of that might not be true based on
> > > > Maciej's research?
> > > > 
> > > >   https://lore.kernel.org/alpine.DEB.2.21.2603101412520.63708@angie.orcam.me.uk/
> > > 
> > > Yes, indeed. In my opinion the consistency aspect is still sufficient
> > > to have this change. What do you think?
> > 
> > Yes, I think so. Will you keep it as going from __ASSEMBLY__ to
> > __ASSEMBLER__? It probably makes more sense that way given there should
> > be no regressions on the compiler side and that is the intended end
> > result?
> 
> I would have stuck to the old name '__ASSEMBLY__', just for robustness
> and because we are late in the cycle.
> Then we can switch it early in the next cycle.

What's the state with this?  Shall this show up in linux-next early this
cycle?

-- 
Nicolas

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

[Nathan Chancellor]

On Sat, Jun 13, 2026 at 12:13:53PM +0200, Nicolas Schier wrote:
> On Tue, Mar 24, 2026 at 08:58:08PM +0100, Thomas Weißschuh wrote:
> > On 2026-03-24 11:35:01-0700, Nathan Chancellor wrote:
> > > On Tue, Mar 24, 2026 at 06:05:34PM +0100, Thomas Weißschuh wrote:
> > > > On 2026-03-13 16:56:18-0700, Nathan Chancellor wrote:
> > > > > It sounds like the "< GCC 3.0" part of that might not be true based on
> > > > > Maciej's research?
> > > > > 
> > > > >   https://lore.kernel.org/alpine.DEB.2.21.2603101412520.63708@angie.orcam.me.uk/
> > > > 
> > > > Yes, indeed. In my opinion the consistency aspect is still sufficient
> > > > to have this change. What do you think?
> > > 
> > > Yes, I think so. Will you keep it as going from __ASSEMBLY__ to
> > > __ASSEMBLER__? It probably makes more sense that way given there should
> > > be no regressions on the compiler side and that is the intended end
> > > result?
> > 
> > I would have stuck to the old name '__ASSEMBLY__', just for robustness
> > and because we are late in the cycle.
> > Then we can switch it early in the next cycle.
> 
> What's the state with this?  Shall this show up in linux-next early this
> cycle?

This fell off my radar. I think the commit message needs some small
updates based on my review upthread but once resent, we should be able
to take it when 7.2-rc1 is out?

-- 
Cheers,
Nathan

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

[Thomas Huth]

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.

  Hi!

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.

  Thanks,
   Thomas

> So this migration may brake users.
> Also during the migration phase, the UAPI headers will use a mix of
> *both* __ASSEMBLY__ and __ASSEMBLER__ at the same time, which is ugly.
> 
> For now make sure that the exported UAPI headers consistently use
> __ASSEMBLER__ as before.
> 
> Link: https://lore.kernel.org/lkml/164baf81-2824-4943-bbc1-4ae8a160c0cc@t-8ch.de/
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> This should go either through kbuild or asm-generic, I think.
> ---
>   scripts/headers_install.sh | 1 +
>   1 file changed, 1 insertion(+)
> 
> 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

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

[Thomas Weißschuh]

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.
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.


Thomas

> > So this migration may brake users.
> > Also during the migration phase, the UAPI headers will use a mix of
> > *both* __ASSEMBLY__ and __ASSEMBLER__ at the same time, which is ugly.
> > 
> > For now make sure that the exported UAPI headers consistently use
> > __ASSEMBLER__ as before.
> > 
> > Link: https://lore.kernel.org/lkml/164baf81-2824-4943-bbc1-4ae8a160c0cc@t-8ch.de/
> > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> > ---
> > This should go either through kbuild or asm-generic, I think.
> > ---
> >   scripts/headers_install.sh | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > 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
> 

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

[Maciej W. Rozycki]

On Thu, 16 Jul 2026, Thomas Weißschuh wrote:

> > > 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.
> 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.

 I believe Thomas specifically refers to the mention of the alleged 
shortcoming of pre-3.0 GCC, which we've since verified not to be true, as 
quoted elsewhere in this thread, so the note needs to be dropped in a 
respin.

  Maciej

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

[Thomas Huth]

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

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

[Thomas Weißschuh]

On 2026-07-16 19:16:26+0100, Maciej W. Rozycki wrote:
> On Thu, 16 Jul 2026, Thomas Weißschuh wrote:
> 
> > > > 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.
> > 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.
> 
>  I believe Thomas specifically refers to the mention of the alleged 
> shortcoming of pre-3.0 GCC, which we've since verified not to be true, as 
> quoted elsewhere in this thread, so the note needs to be dropped in a 
> respin.

It *was* dropped in a respin[0], which is the patch that got applied.

[0] https://lore.kernel.org/lkml/20260630-uapi-assembly-v2-1-8e7bee2fe816@weissschuh.net/

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

[Thomas Weißschuh]

On 2026-07-16 20:52:19+0200, Thomas Huth wrote:
> On 16/07/2026 18.40, Thomas Weißschuh wrote:
> > 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...

Yeah, this is how these things usually go...

> > 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?

As you are the one driving this effort, it would be great if you could
send the patch. If the patch would make it into v7.3 I am also fine with
merging both patches into one if the kbuild maintainers prefer.


Thomas

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

[Thomas Huth]

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

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

[Maciej W. Rozycki]

On Fri, 17 Jul 2026, Thomas Weißschuh wrote:

> > > 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.
> > > 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.
> > 
> >  I believe Thomas specifically refers to the mention of the alleged 
> > shortcoming of pre-3.0 GCC, which we've since verified not to be true, as 
> > quoted elsewhere in this thread, so the note needs to be dropped in a 
> > respin.
> 
> It *was* dropped in a respin[0], which is the patch that got applied.

 Ah, OK.  I didn't get a match on the respin since it changed the subject.

  Maciej

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

[Nicolas Schier]

> 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

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

[Nathan Chancellor]

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

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

[Thomas Weißschuh]

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
> 

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

[Thomas Huth]

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!