Linuxeden开源社区
AMD ISP4 驱动有望按计划合并到 Linux 7.2 内核中
看起来，随着今年晚些时候 Linux 7.2 内核的发布，AMD ISP4 驱动将终于被合并到主线（mainline）中。该驱动是 HP ZBook Ultra G1a Strix Halo 笔记本电脑以及未来其他 AMD Ryzen 笔记本电脑上网络摄像头正常运行所必需的。
在过去一年里，AMD 一直在开发这款新的图像信号处理器（ISP）驱动，并配合 AMDGPU 及其他驱动进行调整，旨在为高端 AMD Ryzen 笔记本电脑提供出色且现代化的摄像头使用体验。截至目前，只有 HP ZBook Ultra G1a 这款高端笔记本使用了 ISP4 技术，但未来预计会有更多笔记本采用该方案。ZBook Ultra G1a 是一款性能强大、非常适合 Linux 系统的笔记本，搭载了 Ryzen AI Max+ PRO 处理器（遗憾的是评测样机已被归还，因此近期未能进行新的基准测试）。然而，其主要限制在于：在主线内核上，摄像头一直无法正常工作。Ubuntu 在其长期支持（LTS）版本中一直通过 OEM 内核携带了该驱动的“树外补丁”（out-of-tree patches），部分用户也手动打补丁来启用摄像头功能。而这次，该驱动终于有望在 Linux 7.2 中实现原生支持。
今日，Linux 媒体子系统维护者 Sakari Ailus 表示，在 AMD ISP4 驱动经历了十轮补丁审查与修改之后，计划将其合并至 Linux 7.2 版本。Sakari 在 Linux 内核邮件列表中说明了他对该驱动的接收计划：
“这一系列补丁已进入我的代码树（amdisp4 分支），我打算在媒体子系统代码树发布 rc1 版本后，提交一个合并请求（PR）用于 Linux 7.2（或者届时我们能走通什么流程就用什么流程）。”
至少现在这个驱动已经有了明确的主线合并路径，尽管错过即将到来的 Linux 7.1 合并窗口令人遗憾，但等到 Ubuntu 26.10 以及其他 2026 年下半年发布的非滚动更新 Linux 发行版时，采用该 IP 的笔记本将获得开箱即用的网络摄像头支持。与英特尔近期需要闭源用户空间库、否则只能回退到基于 CPU 的软 ISP 的 IPU 版本不同，AMD 的 ISP4 方案没有这种用户空间二进制 blob 的限制。
转自 AMD ISP4 Driver On Track To Be Merged For Linux 7.2 – Phoronix
Mesa 开发者确定未来开发将遵循的两项生成式 AI 政策
在先前 Mesa 贡献者指南以及上游 Mesa 开发者之间讨论的基础上，目前就未来 Mesa 项目的开发工作，已确定了两项生成式人工智能（“GenAI”）相关政策。
今天已合并至 Mesa 26.1 Git 分支的，是两项经过广泛讨论并基本达成开发者共识的 GenAI 政策，将用于规范今后的代码提交行为：
-
Mesa 项目不会接受任何通过自主运行的生成式 AI 工具自动提交的代码，除非未来社区就此达成新的共识。因此，即使在补丁（patch(es)）的编写过程中使用了生成式 AI，仍必须由真实的人类开发者来发起 Mesa 的合并请求（merge request），并参与后续的开发者交流。
-
必须披露生成式 AI 的使用情况。Mesa 项目尊重通过生成式 AI 或大语言模型（LLMs）所做出的贡献，但必须进行适当的披露，以便用户清楚了解该补丁是完全由 AI 生成，还是在 AI 辅助下完成的。
Mesa 的 GenAI 相关文档也已相应更新。
此次合并标志着这些新的 Mesa 开发政策正式生效，将指导未来的开发工作。
转自 Mesa Developers Decide On Two Gen AI Policies For Development Moving Forward – Phoronix
谷歌提议将 JSIR 作为 JavaScript 的高级中间表示（IR）
谷歌的工程师们一直在开发一种名为 JSIR（JavaScript 中间表示，JavaScript Intermediate Representation）的高级中间表示形式，用于 JavaScript。他们已经在公司内部将 JSIR 应用于生产环境中的代码分析，并用于将其他代码或字节码转换为 JavaScript，同时也用于对混淆的 JavaScript 代码进行反混淆处理。
今天，谷歌编译器团队的谭志迅（Zhixun Tan）就 JSIR 发布了一项“征求意见请求”（RFC），该提案部分借鉴了 LLVM 和 MLIR 社区的工作成果。迄今为止，大多数 JavaScript 工具都依赖基于抽象语法树（AST）的方法，而非中间表示（IR），而 JSIR 正是为填补这一空白而设计的。
JSIR 的目标是成为一个公开且稳定的中间表示层，能够完整保留所有源代码级别的信息。目前，谷歌的工程师们正在征求 LLVM/MLIR 开发者的意见，了解他们是否对将 JSIR 合并到 MLIR 主线中感兴趣。
感兴趣的开发者可以通过今天的 RFC 了解 JSIR 的技术概览。JSIR 目前已是开源项目，可在 GitHub 上获取。
转自 Google Proposes JSIR As A High-Level IR For JavaScript – Phoronix
Debian 正在研究年龄验证法律将如何影响该项目
随着加利福尼亚州通过了将年龄验证/声明义务落实到操作系统（OS）层面的法律，且美国其他州也在审议类似法案，这一议题在开源世界引发了热烈讨论。对于像 Debian 这样完全由志愿者和社区驱动、与各种商业化 Linux 平台截然不同的项目而言，这些法律可能带来的影响尚在评估之中。
现任 Debian 项目负责人安德烈亚斯·蒂勒（Andreas Tille）在其最近的一次邮件列表更新中提到了这一话题。由于许多即将实施或正在提案中的法律要求在操作系统层面进行年龄认证，并向应用程序和软件包管理器暴露相关的信息或信号，Debian 可能会受到影响。然而，与那些有企业支持、以商业为导向的主流 Linux 发行版不同，目前尚不清楚这类法规将如何具体影响一个完全由志愿者驱动的项目。
目前，Debian、软件公益组织 Software in the Public Interest（SPI）以及其他相关方正在寻求应对不断变化的法律环境的指导。蒂勒在邮件列表更新中写道：
“最近，围绕可能影响自由软件操作系统的新型年龄验证立法，已开始出现相关讨论。特别是《加利福尼亚数字年龄确认法案》（California Digital Age Assurance Act, AB 1043），预计将于2027年生效，该法案引发了关于操作系统和软件分发机制是否必须向应用程序提供与年龄相关的信息的疑问。与此同时，巴西最近通过的一项法律似乎也引入了类似要求，并已正式生效；初步解读表明，该法律可能适用于软件包管理工具等组件。这些发展目前正在 Debian 及其他开源项目内部进行讨论，SPI 已着手寻求法律指导意见。目前情况仍不明确，进一步的分析仍在进行中。”
从非法律专业人士的角度来看，尚不清楚此类法规将如何适用于 Debian 这样一个非营利性、由志愿者驱动的项目。
转自 Debian Is Figuring Out How Age Verification Laws Will Impact It – Phoronix
Wine 11.6 开始重启其 Android 驱动程序的开发
Wine 11.6 已发布，作为这一开源软件最新的双周开发版本。Wine 能够在 Linux、macOS 及其他平台上运行 Windows 游戏和应用程序。
Wine 11.6 的一个显著特点是，它开始重启其 Android 驱动程序的开发。近年来，Wine 在 Android 平台上的工作进展甚少。早在 2024 年，曾有关于“在 Android 上运行 Wine，结合 DXVK/VKD3D-Proton 以及 FEX 来运行 Windows 游戏”的讨论，但此后针对这一名为“Cassia”的项目并未有太多实质性推进。追溯历史，十多年前就曾尝试将 Wine 移植到 Android 上，例如在 Android 设备上运行“纸牌”（Solitaire）这样的经典 Windows 应用。甚至早在 2013 年，就已有“Wine on Android 即将到来，用于运行 Windows 应用”的公开演示：
在 Wine 11.6 中，已包含针对 Android 的构建系统更新，将 Wine 的 Android 代码适配至现代版本的 Gradle 构建工具，并进行了其他调整以兼容更新版本的 Android 系统。我们将拭目以待，此次重启的 Android 驱动开发是否预示着未来版本中将有更广泛的改进计划。
此外，Wine 11.6 的另一项重要更新是：改进了 DLL 加载器的顺序启发式算法（DLL loader order heuristics），以更好地支持游戏模组（game mods）。
同时，该版本还修复了 VBScript 的兼容性问题，并包含了约 28 个其他 bug 修复，属于本次双周开发版本的常规维护内容。这些修复有助于改善包括 .NET 应用程序、StarOffice 办公套件以及多种游戏在内的软件运行表现。
Wine 11.6 的下载地址及相关详细信息，请访问 WineHQ.org 的 GitLab 页面。
英特尔发布面向 Linux 的缓存感知调度第四版补丁
就在一年多以前，Intel 的 Linux 工程师们开始着手开发面向 Linux 的“缓存感知型负载均衡”（cache-aware load balancing），更常见的名称是“缓存感知调度”（Cache Aware Scheduling）。这项功能旨在提升现代 Intel Xeon 和 AMD EPYC 处理器的性能，但至今尚未被合并进主线 Linux 内核。然而，昨天，该功能的第四版补丁（v4）已被提交，供社区审查。
缓存感知调度旨在提升 Linux 在具有多个缓存域（cache domains）的现代 CPU 上的性能表现。调度器会尽量确保共享数据的任务被安排在同一个“末级缓存”（Last Level Cache, LLC）域内运行，从而提高缓存局部性（cache locality），减少缓存未命中（cache misses）和缓存震荡（cache bouncing）现象。
新的“v4”版本补丁在启用 NUMA 负载均衡时，引入了新代码，用于限制在首选 NUMA 节点上进行 CPU 扫描的深度。此外，还针对低负载情况下的负载不平衡问题进行了优化，改进了 LLC 编号（ID）的管理机制，并包含其他多项调整。不过，从根本上说，这一新版补丁系列中的缓存感知调度负载均衡逻辑与之前版本基本保持一致。
根据 Intel 在补丁附信中展示的性能测试结果，该补丁在 Intel Xeon 和 AMD EPYC 平台上均表现出显著的性能提升。我本人对早期版本补丁的测试结果也非常积极：此前的基准测试显示，缓存感知调度在 AMD EPYC “Turin” 架构上展现出巨大潜力，同时也能显著提升 Intel Xeon 6 “Granite Rapids” 处理器的性能。
感兴趣的读者可以在 Linux 内核邮件列表中找到最新的缓存感知调度 v4 补丁。希望这项缓存感知调度功能今年能够成功合入主线 Linux 内核。
转自 Intel Posts Fourth Version Of Cache Aware Scheduling For Linux – Phoronix
Fedora 拒绝使用 systemd 管理用户级环境变量的提案
本周，Fedora 工程与指导委员会（FESCo）拒绝了一项针对 Fedora 45 的变更提案。该提案原本计划使用 systemd 的环境变量生成器（environment generator）功能来管理每个用户的环境变量。
这项 Fedora 45 的提案旨在通过 systemd.environment-generator 来管理用户级环境变量，而不是依赖于个人的 shell 配置文件，例如 ~/.bashrc 及其类似文件（如 ~/.zshrc 等）。
提案方认为，使用 systemd 来管理用户级环境变量，将简化环境变量在不同进程间的传播，并使环境变量的设置不再依赖于用户默认使用的 shell。此外，这一变更还将更友好地支持那些安装了非主流 shell（如 Fish 或 Dash）的用户。
然而，FESCo 委员会最终决定拒绝此项变更。主要担忧在于，这种对 systemd.environment-generator 的使用可能会以无人察觉的方式导致各种问题，尤其是在无 systemd 环境中，例如容器化部署（container deployments）场景下。
该变更提案目前以当前形式已被否决（即“已死亡”）。不过，如果未来能针对“无 systemd 环境”的兼容性问题进行改进，并提供更多配置示例，该提案仍可被修改后重新提交。
转自 Fedora Rejects Proposal To Use systemd For Managing Per-User Environment Variables – Phoronix
Linux 7.1 将带来大量 Rust 编写的图形驱动更新，以及 NVIDIA Nova 驱动的新功能
昨天提交了针对 DRM-Next 的 Rust 功能更新，为即将到来的 2024 年 4 月 Linux 7.1 合并窗口（merge window）做准备。Linux 7.1 中的 Rust 图形/显示驱动代码进一步增强了编程语言的抽象能力，并完善了其他 Rust 基础设施，使使用 Rust 编写的图形驱动具备更强的功能性。
Linux 7.1 的 DRM Rust 更新内容包括：对 DMA 一致性 API 的重构、在 Rust 中实现 GPU buddy 分配器 的抽象、在 Rust 中实现 DRM 共享内存 GEM 辅助抽象、I/O 基础设施的改进、工作队列（workqueue）的优化，以及其他与 Rust 驱动启动相关的组件。
除了核心的 Rust DRM 工作外，还包括对实验性 Arm Mali Tyr 驱动 的改进，以及 Nova Core 驱动 的进展——该驱动旨在成为开源 NVIDIA 显卡驱动 Nouveau 的继任者。
Linux 7.1 中 Nova 驱动的开发工作包括：进一步推进对 NVIDIA Turing GPU 的支持、修复并加固 GPU 系统处理器（GSP）命令队列、支持更大的远程过程调用（RPC）、重构 Falcon 固件处理逻辑、加强固件解析的安全性、为 GSM-RM 日志缓冲区添加 DebugFS 支持，以及其他多项改进。目前，NVIDIA Nova 驱动正在逐步推进中，但尚未准备好供终端用户使用。
Tyr 驱动则根据内核 Rust 编程指南进行了代码调整，修复了 GPU 型号/版本的解码问题，并包含其他一些小的修改。
有关即将在 Linux 7.1 内核周期中引入的所有 Rust DRM 功能变更，请参见此合并请求（pull request）。
转自 A Lot Of Rust Graphics Driver Changes For Linux 7.1, NVIDIA Nova Driver Additions – Phoronix
Ubuntu 26.04 的集成 ROCm 故事仍在持续发展中
Ubuntu 26.04 LTS 距离发布仅剩三周，带来了许多令人期待的新特性，从 GNOME 50 桌面环境到前沿的 Linux 7.0 内核，以及大量软件包的更新。其中，许多用户翘首以盼的一项功能是 Canonical 计划将 AMD 的 ROCm（Radeon Open Compute）直接打包进 Ubuntu 软件仓库中，以便希望使用 AMD 开源 GPU 计算栈的用户获得更简洁、顺畅的安装体验。然而，近几周来读者频繁提问：这一目标是否能在 Ubuntu 26.04 发布当天实现，目前仍是个未知数。
早在去年 12 月 Canonical 的公告中，就曾重点提到 Ubuntu 26.04 将为 ROCm 带来的改进之一是：
“通过
apt install rocm命令即可轻松安装，或作为其他项目（如 ollama-amd）的自动依赖项进行安装。”
但如果你现在在 Ubuntu 26.04 的 post-beta（发布后测试阶段）系统上尝试执行 sudo apt install rocm，你会发现这个关键的 ROCm 元包（meta package）并不存在，其他相关的 ROCm 软件包也尚未被集成进系统。
目前，在 Ubuntu 26.04 的 resolute 软件源中查找 rocm* 相关包时，即使存在的一些包也仍停留在 ROCm 7.1 版本。此外，ROCm-devel PPA（个人软件包存档）也依然停留在较旧的 ROCm 7.1 系列。而实际上，ROCm 7.2 已于今年 1 月发布，带来了许多新功能，并且最近已更新至 ROCm 7.2.1，修复了若干问题，尤其重要的是增强了对 Windows 系统下 WSL2（Windows Subsystem for Linux 2）中 ROCm 的支持。
直到昨天，Canonical 工程师 Talha Can Havadar 提交的软件包上传权限申请才终于获得批准。Talha 表示将负责在 Ubuntu 中维护 ROCm 软件包。接下来我们拭目以待：这项 ROCm 支持能否在 4 月 23 日 Ubuntu 26.04 LTS 正式发布前的“功能冻结期”内完全落实并更新到位，还是会在发布之后才逐步实现。至少目前来看，想要在 Ubuntu 上使用 ROCm 的用户，最好还是继续使用 AMD 官方提供的最新上游 ROCm 软件包。
转自 The Integrated ROCm Story For Ubuntu 26.04 Still Playing Out – Phoronix