[PATCH v2] drm/xe: Don't use UTS_RELEASE directly

[PATCH v2] drm/xe: Don't use UTS_RELEASE directly

[Uwe Kleine-König (The Capable Hub)]

UTS_RELEASE evaluates to a static string and changes quite easily (e.g.
uncommitted changes in the source tree or new commits). So when checking
if a patch introduces changes to the resulting binary each usage of
UTS_RELEASE is source of annoyance.

Instead of using UTS_RELEASE directly use init_utsname()->release which
evaluates to the same string but with that a change of UTS_RELEASE
doesn't affect xe_devcoredump.o.

Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,

(implicit) v1 of this patch is available at 
https://lore.kernel.org/20260427160902.1126027-2-u.kleine-koenig%40baylibre.com.

The only changes since then is that instead of dropping the kernel line,
init_utsname()->release is used, which is nearly what Jani Nikula
suggested.

Best regards
Uwe

 drivers/gpu/drm/xe/xe_devcoredump.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c
index 558a1a9841a0..07c7c89240d8 100644
--- a/drivers/gpu/drm/xe/xe_devcoredump.c
+++ b/drivers/gpu/drm/xe/xe_devcoredump.c
@@ -8,7 +8,7 @@
 
 #include <linux/ascii85.h>
 #include <linux/devcoredump.h>
-#include <generated/utsrelease.h>
+#include <linux/utsname.h>
 
 #include <drm/drm_managed.h>
 
@@ -101,7 +101,7 @@ static ssize_t __xe_devcoredump_read(char *buffer, ssize_t count,
 
 	drm_puts(&p, "**** Xe Device Coredump ****\n");
 	drm_printf(&p, "Reason: %s\n", ss->reason);
-	drm_puts(&p, "kernel: " UTS_RELEASE "\n");
+	drm_printf(&p, "kernel: %s\n", init_utsname()->release);
 	drm_puts(&p, "module: " KBUILD_MODNAME "\n");
 
 	ts = ktime_to_timespec64(ss->snapshot_time);

base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
-- 
2.47.3

Re: [PATCH v2] drm/xe: Don't use UTS_RELEASE directly

[Jani Nikula]

On Tue, 28 Apr 2026, Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> wrote:
> UTS_RELEASE evaluates to a static string and changes quite easily (e.g.
> uncommitted changes in the source tree or new commits). So when checking
> if a patch introduces changes to the resulting binary each usage of
> UTS_RELEASE is source of annoyance.
>
> Instead of using UTS_RELEASE directly use init_utsname()->release which
> evaluates to the same string but with that a change of UTS_RELEASE
> doesn't affect xe_devcoredump.o.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>

Reviewed-by: Jani Nikula <jani.nikula@intel.com>

> ---
> Hello,
>
> (implicit) v1 of this patch is available at 
> https://lore.kernel.org/20260427160902.1126027-2-u.kleine-koenig%40baylibre.com.
>
> The only changes since then is that instead of dropping the kernel line,
> init_utsname()->release is used, which is nearly what Jani Nikula
> suggested.

Almost the same, but better. ;)

I wonder if most UTS_RELEASE uses in the kernel should be changed the
same way?


BR,
Jani.


>
> Best regards
> Uwe
>
>  drivers/gpu/drm/xe/xe_devcoredump.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c
> index 558a1a9841a0..07c7c89240d8 100644
> --- a/drivers/gpu/drm/xe/xe_devcoredump.c
> +++ b/drivers/gpu/drm/xe/xe_devcoredump.c
> @@ -8,7 +8,7 @@
>  
>  #include <linux/ascii85.h>
>  #include <linux/devcoredump.h>
> -#include <generated/utsrelease.h>
> +#include <linux/utsname.h>
>  
>  #include <drm/drm_managed.h>
>  
> @@ -101,7 +101,7 @@ static ssize_t __xe_devcoredump_read(char *buffer, ssize_t count,
>  
>  	drm_puts(&p, "**** Xe Device Coredump ****\n");
>  	drm_printf(&p, "Reason: %s\n", ss->reason);
> -	drm_puts(&p, "kernel: " UTS_RELEASE "\n");
> +	drm_printf(&p, "kernel: %s\n", init_utsname()->release);
>  	drm_puts(&p, "module: " KBUILD_MODNAME "\n");
>  
>  	ts = ktime_to_timespec64(ss->snapshot_time);
>
> base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731

-- 
Jani Nikula, Intel

Re: [PATCH v2] drm/xe: Don't use UTS_RELEASE directly

[Uwe Kleine-König (The Capable Hub)]

[-- Attachment #1: Type: text/plain, Size: 1278 bytes --]

On Tue, Apr 28, 2026 at 02:09:31PM +0300, Jani Nikula wrote:
> On Tue, 28 Apr 2026, Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> wrote:
> > UTS_RELEASE evaluates to a static string and changes quite easily (e.g.
> > uncommitted changes in the source tree or new commits). So when checking
> > if a patch introduces changes to the resulting binary each usage of
> > UTS_RELEASE is source of annoyance.
> >
> > Instead of using UTS_RELEASE directly use init_utsname()->release which
> > evaluates to the same string but with that a change of UTS_RELEASE
> > doesn't affect xe_devcoredump.o.
> >
> > Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> 
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>

Thanks!

> > (implicit) v1 of this patch is available at 
> > https://lore.kernel.org/20260427160902.1126027-2-u.kleine-koenig%40baylibre.com.
> >
> > The only changes since then is that instead of dropping the kernel line,
> > init_utsname()->release is used, which is nearly what Jani Nikula
> > suggested.
> 
> Almost the same, but better. ;)
> 
> I wonder if most UTS_RELEASE uses in the kernel should be changed the
> same way?

I have adapting these on my todo list.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2] drm/xe: Don't use UTS_RELEASE directly

[Rodrigo Vivi]

On Tue, Apr 28, 2026 at 02:09:31PM +0300, Jani Nikula wrote:
> On Tue, 28 Apr 2026, Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> wrote:
> > UTS_RELEASE evaluates to a static string and changes quite easily (e.g.
> > uncommitted changes in the source tree or new commits). So when checking
> > if a patch introduces changes to the resulting binary each usage of
> > UTS_RELEASE is source of annoyance.
> >
> > Instead of using UTS_RELEASE directly use init_utsname()->release which
> > evaluates to the same string but with that a change of UTS_RELEASE
> > doesn't affect xe_devcoredump.o.
> >
> > Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> 
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>

Cc: José Roberto de Souza <jose.souza@intel.com>

Jose, ack on this?!

I'm afraid this could break the current Mesa parser, so better checking first...

> 
> > ---
> > Hello,
> >
> > (implicit) v1 of this patch is available at 
> > https://lore.kernel.org/20260427160902.1126027-2-u.kleine-koenig%40baylibre.com.
> >
> > The only changes since then is that instead of dropping the kernel line,
> > init_utsname()->release is used, which is nearly what Jani Nikula
> > suggested.
> 
> Almost the same, but better. ;)
> 
> I wonder if most UTS_RELEASE uses in the kernel should be changed the
> same way?
> 
> 
> BR,
> Jani.
> 
> 
> >
> > Best regards
> > Uwe
> >
> >  drivers/gpu/drm/xe/xe_devcoredump.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c
> > index 558a1a9841a0..07c7c89240d8 100644
> > --- a/drivers/gpu/drm/xe/xe_devcoredump.c
> > +++ b/drivers/gpu/drm/xe/xe_devcoredump.c
> > @@ -8,7 +8,7 @@
> >  
> >  #include <linux/ascii85.h>
> >  #include <linux/devcoredump.h>
> > -#include <generated/utsrelease.h>
> > +#include <linux/utsname.h>
> >  
> >  #include <drm/drm_managed.h>
> >  
> > @@ -101,7 +101,7 @@ static ssize_t __xe_devcoredump_read(char *buffer, ssize_t count,
> >  
> >  	drm_puts(&p, "**** Xe Device Coredump ****\n");
> >  	drm_printf(&p, "Reason: %s\n", ss->reason);
> > -	drm_puts(&p, "kernel: " UTS_RELEASE "\n");
> > +	drm_printf(&p, "kernel: %s\n", init_utsname()->release);
> >  	drm_puts(&p, "module: " KBUILD_MODNAME "\n");
> >  
> >  	ts = ktime_to_timespec64(ss->snapshot_time);
> >
> > base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
> 
> -- 
> Jani Nikula, Intel

Re: [PATCH v2] drm/xe: Don't use UTS_RELEASE directly

[Souza, Jose]

On Tue, 2026-04-28 at 15:58 -0400, Rodrigo Vivi wrote:
> On Tue, Apr 28, 2026 at 02:09:31PM +0300, Jani Nikula wrote:
> > On Tue, 28 Apr 2026, Uwe Kleine-König (The Capable Hub)
> > <u.kleine-koenig@baylibre.com> wrote:
> > > UTS_RELEASE evaluates to a static string and changes quite easily
> > > (e.g.
> > > uncommitted changes in the source tree or new commits). So when
> > > checking
> > > if a patch introduces changes to the resulting binary each usage
> > > of
> > > UTS_RELEASE is source of annoyance.
> > > 
> > > Instead of using UTS_RELEASE directly use init_utsname()->release
> > > which
> > > evaluates to the same string but with that a change of
> > > UTS_RELEASE
> > > doesn't affect xe_devcoredump.o.
> > > 
> > > Signed-off-by: Uwe Kleine-König (The Capable Hub)
> > > <u.kleine-koenig@baylibre.com>
> > 
> > Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> 
> Cc: José Roberto de Souza <jose.souza@intel.com>
> 
> Jose, ack on this?!
> 
> I'm afraid this could break the current Mesa parser, so better
> checking first...
> 

It will not cause any problems.

Acked-by: José Roberto de Souza <jose.souza@intel.com>

> > 
> > > ---
> > > Hello,
> > > 
> > > (implicit) v1 of this patch is available at 
> > > https://lore.kernel.org/20260427160902.1126027-2-u.kleine-koenig%40baylibre.com
> > > .
> > > 
> > > The only changes since then is that instead of dropping the
> > > kernel line,
> > > init_utsname()->release is used, which is nearly what Jani Nikula
> > > suggested.
> > 
> > Almost the same, but better. ;)
> > 
> > I wonder if most UTS_RELEASE uses in the kernel should be changed
> > the
> > same way?
> > 
> > 
> > BR,
> > Jani.
> > 
> > 
> > > 
> > > Best regards
> > > Uwe
> > > 
> > >  drivers/gpu/drm/xe/xe_devcoredump.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c
> > > b/drivers/gpu/drm/xe/xe_devcoredump.c
> > > index 558a1a9841a0..07c7c89240d8 100644
> > > --- a/drivers/gpu/drm/xe/xe_devcoredump.c
> > > +++ b/drivers/gpu/drm/xe/xe_devcoredump.c
> > > @@ -8,7 +8,7 @@
> > >  
> > >  #include <linux/ascii85.h>
> > >  #include <linux/devcoredump.h>
> > > -#include <generated/utsrelease.h>
> > > +#include <linux/utsname.h>
> > >  
> > >  #include <drm/drm_managed.h>
> > >  
> > > @@ -101,7 +101,7 @@ static ssize_t __xe_devcoredump_read(char
> > > *buffer, ssize_t count,
> > >  
> > >  	drm_puts(&p, "**** Xe Device Coredump ****\n");
> > >  	drm_printf(&p, "Reason: %s\n", ss->reason);
> > > -	drm_puts(&p, "kernel: " UTS_RELEASE "\n");
> > > +	drm_printf(&p, "kernel: %s\n", init_utsname()->release);
> > >  	drm_puts(&p, "module: " KBUILD_MODNAME "\n");
> > >  
> > >  	ts = ktime_to_timespec64(ss->snapshot_time);
> > > 
> > > base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
> > 
> > -- 
> > Jani Nikula, Intel

Re: [PATCH v2] drm/xe: Don't use UTS_RELEASE directly

[Rodrigo Vivi]

On Tue, Apr 28, 2026 at 04:01:41PM -0400, Souza, Jose wrote:
> On Tue, 2026-04-28 at 15:58 -0400, Rodrigo Vivi wrote:
> > On Tue, Apr 28, 2026 at 02:09:31PM +0300, Jani Nikula wrote:
> > > On Tue, 28 Apr 2026, Uwe Kleine-König (The Capable Hub)
> > > <u.kleine-koenig@baylibre.com> wrote:
> > > > UTS_RELEASE evaluates to a static string and changes quite easily
> > > > (e.g.
> > > > uncommitted changes in the source tree or new commits). So when
> > > > checking
> > > > if a patch introduces changes to the resulting binary each usage
> > > > of
> > > > UTS_RELEASE is source of annoyance.
> > > > 
> > > > Instead of using UTS_RELEASE directly use init_utsname()->release
> > > > which
> > > > evaluates to the same string but with that a change of
> > > > UTS_RELEASE
> > > > doesn't affect xe_devcoredump.o.
> > > > 
> > > > Signed-off-by: Uwe Kleine-König (The Capable Hub)
> > > > <u.kleine-koenig@baylibre.com>
> > > 
> > > Reviewed-by: Jani Nikula <jani.nikula@intel.com>
> > 
> > Cc: José Roberto de Souza <jose.souza@intel.com>
> > 
> > Jose, ack on this?!
> > 
> > I'm afraid this could break the current Mesa parser, so better
> > checking first...
> > 
> 
> It will not cause any problems.
> 
> Acked-by: José Roberto de Souza <jose.souza@intel.com>

Thank you all, pushed to drm-xe-next

> 
> > > 
> > > > ---
> > > > Hello,
> > > > 
> > > > (implicit) v1 of this patch is available at 
> > > > https://lore.kernel.org/20260427160902.1126027-2-u.kleine-koenig%40baylibre.com
> > > > .
> > > > 
> > > > The only changes since then is that instead of dropping the
> > > > kernel line,
> > > > init_utsname()->release is used, which is nearly what Jani Nikula
> > > > suggested.
> > > 
> > > Almost the same, but better. ;)
> > > 
> > > I wonder if most UTS_RELEASE uses in the kernel should be changed
> > > the
> > > same way?
> > > 
> > > 
> > > BR,
> > > Jani.
> > > 
> > > 
> > > > 
> > > > Best regards
> > > > Uwe
> > > > 
> > > >  drivers/gpu/drm/xe/xe_devcoredump.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c
> > > > b/drivers/gpu/drm/xe/xe_devcoredump.c
> > > > index 558a1a9841a0..07c7c89240d8 100644
> > > > --- a/drivers/gpu/drm/xe/xe_devcoredump.c
> > > > +++ b/drivers/gpu/drm/xe/xe_devcoredump.c
> > > > @@ -8,7 +8,7 @@
> > > >  
> > > >  #include <linux/ascii85.h>
> > > >  #include <linux/devcoredump.h>
> > > > -#include <generated/utsrelease.h>
> > > > +#include <linux/utsname.h>
> > > >  
> > > >  #include <drm/drm_managed.h>
> > > >  
> > > > @@ -101,7 +101,7 @@ static ssize_t __xe_devcoredump_read(char
> > > > *buffer, ssize_t count,
> > > >  
> > > >  	drm_puts(&p, "**** Xe Device Coredump ****\n");
> > > >  	drm_printf(&p, "Reason: %s\n", ss->reason);
> > > > -	drm_puts(&p, "kernel: " UTS_RELEASE "\n");
> > > > +	drm_printf(&p, "kernel: %s\n", init_utsname()->release);
> > > >  	drm_puts(&p, "module: " KBUILD_MODNAME "\n");
> > > >  
> > > >  	ts = ktime_to_timespec64(ss->snapshot_time);
> > > > 
> > > > base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
> > > 
> > > -- 
> > > Jani Nikula, Intel