public inbox for drm-ai-reviews@public-inbox.freedesktop.org
 help / color / mirror / Atom feed
* [PATCH] drm/vmwgfx: Don't use UTS_RELEASE directly
@ 2026-05-04  7:34 Uwe Kleine-König (The Capable Hub)
  2026-05-04 22:34 ` Claude review: " Claude Code Review Bot
  2026-05-04 22:34 ` Claude Code Review Bot
  0 siblings, 2 replies; 3+ messages in thread
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-04  7:34 UTC (permalink / raw)
  To: Zack Rusin, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann
  Cc: Markus Schneider-Pargmann, Broadcom internal kernel review list,
	dri-devel, linux-kernel

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

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

an alternative way to address this is to drop the kernel version string
completely. But I'm not sure how redundant this really is so I chose the
init_utsname() approach.

Best regards
Uwe

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

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 0f101aedb49a..12f5f288ae15 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -24,7 +24,6 @@
 #include <drm/drm_sysfs.h>
 #include <drm/ttm/ttm_range_manager.h>
 #include <drm/ttm/ttm_placement.h>
-#include <generated/utsrelease.h>
 
 #ifdef CONFIG_X86
 #include <asm/hypervisor.h>
@@ -35,6 +34,7 @@
 #include <linux/dma-mapping.h>
 #include <linux/module.h>
 #include <linux/pci.h>
+#include <linux/utsname.h>
 #include <linux/version.h>
 #include <linux/vmalloc.h>
 
@@ -1115,7 +1115,7 @@ static int vmw_driver_load(struct vmw_private *dev_priv, u32 pci_id)
 	vmw_print_sm_type(dev_priv);
 	vmw_host_printf("vmwgfx: Module Version: %d.%d.%d (kernel: %s)",
 			VMWGFX_DRIVER_MAJOR, VMWGFX_DRIVER_MINOR,
-			VMWGFX_DRIVER_PATCHLEVEL, UTS_RELEASE);
+			VMWGFX_DRIVER_PATCHLEVEL, init_utsname()->release);
 	vmw_write_driver_id(dev_priv);
 
 	dev_priv->pm_nb.notifier_call = vmwgfx_pm_notifier;

base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
-- 
2.47.3


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Claude review: drm/vmwgfx: Don't use UTS_RELEASE directly
  2026-05-04  7:34 [PATCH] drm/vmwgfx: Don't use UTS_RELEASE directly Uwe Kleine-König (The Capable Hub)
@ 2026-05-04 22:34 ` Claude Code Review Bot
  2026-05-04 22:34 ` Claude Code Review Bot
  1 sibling, 0 replies; 3+ messages in thread
From: Claude Code Review Bot @ 2026-05-04 22:34 UTC (permalink / raw)
  To: dri-devel-reviews

Overall Series Review

Subject: drm/vmwgfx: Don't use UTS_RELEASE directly
Author: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20=28The=20Capable=20Hub=29?=
 <u.kleine-koenig@baylibre.com>
Patches: 1
Reviewed: 2026-05-05T08:34:38.174808

---

This is a single, well-motivated patch that replaces direct use of the `UTS_RELEASE` compile-time macro with the runtime-equivalent `init_utsname()->release` in the vmwgfx driver. The practical benefit is improved build reproducibility: changes to `UTS_RELEASE` (which fluctuates with any uncommitted changes or new commits) no longer force recompilation of `vmwgfx_drv.o`. The runtime value is identical, so there is no behavioral change.

The approach is sound, follows existing kernel conventions (i915 and xe already use `init_utsname()->release`), and the patch is clean and minimal. **No issues found.**

---
Generated by Claude Code Patch Reviewer

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Claude review: drm/vmwgfx: Don't use UTS_RELEASE directly
  2026-05-04  7:34 [PATCH] drm/vmwgfx: Don't use UTS_RELEASE directly Uwe Kleine-König (The Capable Hub)
  2026-05-04 22:34 ` Claude review: " Claude Code Review Bot
@ 2026-05-04 22:34 ` Claude Code Review Bot
  1 sibling, 0 replies; 3+ messages in thread
From: Claude Code Review Bot @ 2026-05-04 22:34 UTC (permalink / raw)
  To: dri-devel-reviews

Patch Review

**Verdict: Looks good / No issues.**

The patch makes three changes:

1. **Removes `#include <generated/utsrelease.h>`** — this header provided the `UTS_RELEASE` macro, no longer needed.

2. **Adds `#include <linux/utsname.h>`** — provides `init_utsname()`. Placed in correct alphabetical order among the `<linux/...>` includes.

3. **Replaces the macro usage:**
```c
-			VMWGFX_DRIVER_PATCHLEVEL, UTS_RELEASE);
+			VMWGFX_DRIVER_PATCHLEVEL, init_utsname()->release);
```

This is the only usage of `UTS_RELEASE` in the file, so the include swap is complete. The `init_utsname()->release` accessor returns the same NUL-terminated string at runtime, so the `%s` format specifier in `vmw_host_printf` works identically.

The pattern is already established in other DRM drivers — `drivers/gpu/drm/i915/i915_gpu_error.c` and `drivers/gpu/drm/xe/xe_guc_log.c` both use `init_utsname()->release` the same way.

The commit message clearly explains the motivation (build reproducibility / avoiding unnecessary recompilation) and the cover letter honestly notes that dropping the version string entirely would be an alternative, which shows good judgment in choosing the less disruptive option.

**Reviewed-by worthy.** No correctness, style, or design concerns.

---
Generated by Claude Code Patch Reviewer

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-05-04 22:34 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-04  7:34 [PATCH] drm/vmwgfx: Don't use UTS_RELEASE directly Uwe Kleine-König (The Capable Hub)
2026-05-04 22:34 ` Claude review: " Claude Code Review Bot
2026-05-04 22:34 ` Claude Code Review Bot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox