Linux Kernel 6y系列主要发布记录
2023-11-20 21:04:28 阿炯

上接《Linux Kernel 6x系列主要发布记录》。

Linux Kernel 6.6 确认成为 LTS 版本

Greg Kroah-Hartman 已经于2023年11月20日宣布 Linux Kernel 6.6 版本为长期支持 (LTS) 版本;支持期限到 2026 年 12 月。

6.6 版本的内核于 2023 年 10 月 29 日正式发布,是一次包含了新功能、硬件支持、安全增强和性能改进的重大更新。具体包括有:引入了 EEVDF scheduler,最终实现了对 Intel Shadow Stack 的支持,为 Nouveau DRM 驱动程序添加了 Mesa NVK Vulkan 驱动程序所需的 user-space API,继续支持即将到来的 Intel 和 AMD 平台,以及大量的其他驱动程序改进和一些不错的性能优化等。


一般来说,年度 LTS 内核往往是该日历年的最后一个稳定内核版本。Linux 6.6 于十月底发布,Linux 6.7 预计可能会在 2023 年的最后几天或者 2024 年年初达到稳定。但考虑到 6.7 版本规模较大,且年末的假期往往会放慢测试和 bug 修复的速度,导致相关周期拖长,因此 6.7 版本大概率还是可能在 2024 年初登陆。

目前 Kernel.org 已更新相关版本信息。Linux 6.6 生命周期将将截止 2026 年 12 月;与此同时,Linux 6.1、5.15 和 5.10 也将于 2026 年 12 月结束生命周期。因此根据当下的政策,Linux 6.6 LTS 将在未来三年内得到维护,不过也有消息称内核开发人员一直在讨论将 LTS 支持期缩短为 2 年。

更多详情可查看此处

联想向 Linux 内核提交补丁,为最新款 ThinkPad 优化性能

联想于2023年11月下旬提交了一个 Linux 内核驱动程序补丁,专为其最新的 ThinkPad 笔记本电脑构建,目标是优化性能表现 (Ultra-Performance Capability) —— 确保在开启「性能」模式的 ACPI 平台配置下,硬件能够实现最佳 Linux 性能的同时,在平衡和省电模式下保持最佳电源节省。

根据补丁的描述,这项改进性能模式的 ThinkPad ACPI 驱动程序已在 ThinkPad T14 G4 AMD 型号上通过了测试。不过补丁仍在 review 阶段。按照日程进度,它应该会在 v6.8 内核开发周期准备就绪。

Linux 内核放弃支持过时的图形驱动基础设施

Linux 内核团队于2023年11朋下旬准备删除支持旧的和过时的图形驱动程序的基础设施。早在 Linux 6.3 内核中就已经移除了许多旧版的 DRM 驱动程序,现在的补丁进一步删除了支持这些旧的用户空间模式设置图形/显示驱动程序的基础设施。

在 Linux 6.3 内核中,ATI Rage 128、3Dfx、S3 Savage、Intel 810、SiS、VIA 和 Matrox MGA DRM 驱动程序被淘汰。这是为了清除 DRI1 时代过时 GPU 驱动程序的努力的一部分。现在 SUSE 工程师 Thomas Zimmermann 计划进一步删除用户空间模式设置的基础设施。他认为,由于 Linux 6.6 是今年的长期支持版本(LTS)内核。现在是一个很好的时机来删除这个基础设施。如果有人仍在使用这些旧的驱动程序或类似的驱动程序,他们可以继续使用 Linux 6.6 LTS。

Zimmermann 在 dri-devel 上写道:旧的用户空间模式设置驱动程序已经在 Linux v6.3 中被删除。没有人抱怨或要求它们的恢复。现在是时候从 DRM 核心中删除这些驱动程序的基础设施了。

最近的 Linux v6.6 已被指定为长期支持版本,因此任何剩余的用户还有几年时间来购买新的显卡。通过简单的 drm 仍然支持这些旧设备。将适当的驱动程序与内核模式设置合并也是一个选择。

补丁 1 到 7 修复了在删除驱动程序过程中被遗忘的一些微不足道的问题。

补丁 8 和 9 删除了旧的 ioctl 接口。其中一个操作与其他操作不同,因此它有自己的补丁。

补丁 10 到 12 从 DRM 中删除了旧的源代码。随着这些代码的消失,补丁 13 中的 AGP 代码也可以简化。以前有一个用于用户空间模式设置的设备文件 /dev/agpgart,现在已经过时了。

这 14 个补丁在直接渲染管理器子系统中消除了另外 8000 行旧代码。如果没有提出异议,这个旧的用户空间模式设置基础设施的删除可能会在新的一年的 Linux 6.8 内核周期中发生。

这项工作主要是为了清除过时的 GPU 驱动程序,并为用户提供更好的性能和稳定性。对于依赖旧版驱动程序的用户,他们可以继续使用 Linux 6.6 LTS,直到他们准备好升级到支持新的图形驱动程序的版本。

Linux 6.8 将更新 Zstd 代码以获得更好的压缩性能

Linux 6.8 内核计划在2024年升级其 Zstd 代码,以提供更好的压缩性能。在 Linux 6.2 中,内核的 Zstd 压缩/解压缩代码已经根据 Zstd 1.5 的最新状态进行了更新。而在 6.8 内核中,计划升级到 Zstd 1.5.5 版本,这将提供更好的压缩性能。

这次 Zstd 升级对 Linux 内核的动力之一是英特尔希望在 Linux 内核中使用更新的 Zstd 版本,因为它公开了 Zstd 的外部匹配提供程序 API,从而允许 QuickAssist 技术(QAT)加速 LZ 匹配查找阶段。这对于那些拥有 QAT 硬件或将 QAT 加速集成到 Xeon Sapphire Rapids 和即将推出的 Emerald Rapids 处理器的用户来说是个好消息。

除了满足英特尔的需求之外,内核中更新的 Zstd 代码经过测试,发现在写入 + 压缩时间上可以减少约 6%。然而,读取 + 解压缩时间略有增加。Zstd 1.5.5 本身是在今年 4 月发布的,其中包含了一些性能改进、修复和其他变更。目前可以在邮件列表的补丁中找到适用于 Linux 内核的 Zstd 1.5.5 版本,内核维护者计划在 Linux 6.8 合并窗口提交这项工作。

这次 Zstd 代码的升级将为 Linux 内核带来更好的压缩性能,这对于文件系统驱动程序的透明文件系统压缩 / 解压缩、将各种内核资源压缩为 Zstd 格式等方面都是有益的。

Jonathan Corbet 2024 预言

LWN 网站联合创始人兼 Linux 内核维护者 Jonathan Corbet 于2024年1月上旬分享了他对 2024 年的预测,内容包括 Linux 内核社区的变化、企业级 Linux 发行版的市场受到冲击、Firefox 的未来、开源生成式人工智能 (Gen AI) 关注度更高、BPF 大有作为、Python no-GIL 取得成功,以及开源项目维护者面临的危机,等等。

下面简单介绍 Jonathan Corbet 的预测内容。

一、Linux 内核社区开始不再将邮件列表作为其开发流程的核心。这一转变会很缓慢,并且引起许多内核开发者的强烈抵制。但在这个连 Linus 老大都说要做出改变的时代,不可思议的事情很有可能会发生。

二、Linux 6.12 将是下一个长期稳定版内核,预计 2024 年 12 月 1 日发布(除非 Linus 拒绝在美国感恩节假期后立即发布,这种情况下将在一周后推出)。

三、首批用户可见的 Rust 代码最早可能在 Linux 6.8 中合并到内核。这些代码初始阶段应该不会支持许多系统,但它标志着一个重要转变:一旦 Rust 用于用户可见的功能,内核社区将不再可以轻易放弃对该语言的支持。换句话说,将用户可见的 Rust 代码合并到内核中将宣告 Rust 试验取得成功。

四、红帽的企业级 Linux 发行版市场将在 2024 年受到冲击。该市场的控制权此前基本由红帽 RHEL 统治,但随着这一领域的竞争日趋激烈,打造稳定版 Linux 不需要再依赖 RHEL,供应商和用户有许多方法可以从 RHEL 手中夺走部分市场。

五、谷歌在 Chrome 强推 "Manifest V3" 将引起广泛抵制,但如果 Mozilla 今年只是押注人工智能,没有将重心放在 Firefox 上 —— 帮助全世界摆脱浏览器垄断,Firefox 可能再也没有这样的机会来扩大市场份额。

六、开源生成式人工智能 (Gen AI) 在 2024 将受到更广泛关注。部分原因是,在该领域已经有案例证明开源项目比私有项目更具竞争力。而且这些私有平台今年将出现更多关于版权纠纷的事件 —— 从而让更多人将目光转移到开源项目上。

七、对 BPF 而言,今年将是重要的一年。这并不奇怪,因为过去几年也是如此。像可扩展调度程序类这样的项目似乎不会消失。与此同时,思科最近宣布收购 Isovalent,这可能会为 BPF 开发带来新的资源,当然也可能会像许多企业收购一样 —— 毁掉一个重要的 BPF 开发团队。

八、支持自由线程 (no-GIL) 的首个 Python 版本在 10 月发布,并将取得一定的成功。

九、过分追求指标将成为一个更大的问题。这些指标包括: CVE 数量、提交的错误报告、commit 数量、“审查” 的补丁、toots 提升、获得的讨论论坛徽章,等等。

十、开源项目维护者面临的危机在 2024 将会加剧。自由开源软件社区中有许多项目被广泛依赖,但几乎没有得到支持。因此,这些项目往往会面临进展缓慢、背负大量技术债、安全问题等等。此现象并不是新鲜事,对于任何一直关注的人来说,它也不是隐藏的。但从所有迹象来看,重度依赖开源项目的公司在 2024 年并不会为它们提供更多的支持。

Linux Kernel 6.7 正式发布

Linus 于2024年1月上旬在内核邮件列表宣布正式推出 Linux Kernel 6.7。据称此版本是有史以来合并数最多的版本之一,包含 17k+ 个非合并 commit,实际合并的超过 1000 个,主要变化如下:
主线内核已合并实验性 Bcachefs 文件系统
现在默认启用 Intel Meteor Lake 显卡支持
在 x86-64 内核上启用/禁用 32 位模拟的选项
KVM 支持 LoongArch 虚拟化
KVM on RISC-V 支持 Smstateen 扩展
默认启用 Intel Meteor Lake 图形支持,同时还引入了针对 Intel Xe2Lunar Lake 图形的支持
为 Nouveau 开源图形驱动程序新增对 NVIDIA GPU 系统处理器(GSP)固件的支持,从而带来更好的电源管理性能,还包括 Nouveau 设置中的 RTX 40 加速
USB Type-C 驱动现已支持 DP Alt Mode 2.1
AMD Seamless Boot 现适用于更多 AMD 硬件
F2FS 现已支持更大的页面大小
Btrfs 功能增强,例如添加了 FSID(临时文件系统 ID)支持(Valve 希望为 Steam Deck 的  Steam OS 引入这一功能)
AppArmor 访问控制现在可以应用于 io_uring,并支持创建用户命名空间
添加了 Rust 对工作队列的绑定,并升级到 Rust 1.73 工具链
对 perf 工具进行了大量改进和功能更新
移除了古老的 videobuf 层
对 Logitech HID++ 进行了调整
ASUS WMI 驱动增加了对 Screenpad 的支持

Linux Kernel 6.8:网络优化,英特尔Xe GPU驱动,第一个Rust驱动

随着Linux 6.7的发布,v6.8版本在1月中旬开始进入了窗口合并期。来展望一下Linux内核在2024年的工作,主要介绍两个硬件驱动方面的消息,一个是关于网络性能方面,一个是关于Rust驱动的。

并发TCP性能提高

在网络方面除了通常的新有线/无线网络硬件支持和大型Linux网络子系统中的其他常规改动之外,内核还对核心网络代码进行了一些关键改进,这些改进可以在并发的情况下使TCP性能提高约40%。对核心网络结构进行了分析和重组。这项工作的重点是优化缓存行消耗并添加保护措施以确保未来的更改不会倒退。反过来,这种核心网络结构的优化使许多并发连接的TCP性能提高了40%或更多!


这项由于源于谷歌相关人员,他们对网络代码的缓存线优化工作。该补丁系列尝试重新组织核心网络堆栈变量,以最大限度地减少数据传输阶段的缓存行消耗。具体来说,研究了TCP/IP堆栈和TCP中的快速路径定义。

特别是对于AMD EPYC服务器来说,这是一个巨大的改进。感谢谷歌继续推动这些非常诱人的低级内核优化的人们。

英特尔Xe内核GPU驱动程序

Direct Rendering Manager (DRM) 内核图形/显示驱动程序更新包括新的英特尔 "Xe"DRM 和 PowerVR Imagination 驱动程序、实验形式的 AMD 色彩管理属性、Raspberry Pi 5 图形支持等。

除了Xe显卡驱动程序之外,英特尔还引入了对现有软件包的下一代支持,例如英特尔的VC Intrinsics,它已经获得了对英特尔Arrow Lake和Lunar Lake图形架构的支持。这意味着 Xe-LPG+(Arrow Lake/Alchemist)和 Xe2(Lunar Lake/Battlemage)架构已获得该软件项目的支持。

与其他平台相比,英特尔在 Linux 中首次推出 Arc 驱动程序的起步相当缓慢,主要是因为 Team Blue 在提供增强驱动程序功能方面有点晚了。 不过,经过两年的开发,Intel终于将其“改版”的Xe内核显卡驱动提交到了主线内核中。但 Linus Torvalds 最近在合并相关代码时却发现,一些新提交的 Intel Xe 驱动程序代码"严重缺乏"测试。对此他在内核邮件列表中表达了自己的不满:你的测试严重不足。甚至无法构建,原因似乎在于该 commit b49e894c3fd8 ("drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library") 将 "intel_wakeref_t" 类型从 "deep_stack_handle_t" 改为了 "unsigned long"......

真令人不悦。我已经修复了那个损坏的 Xe compat 头文件并完成了构建,但这绝对不是事情的本来应该有的样子。我怎么会遇到这种情况?竟然会没有进行任何构建测试。

为什么 %^!@$% 头文件会包含 C 文件?无论如何,这个错误都不应该发生。与以前的一些 “火爆” 回复相比,Linus 这次的措辞可以说是算的上温和,并且也提出了一些合理的问题。事实上,在 2023 年底的 Linux 基金会的日本开源峰会上,Linus 就表示自己已经收敛了脾气,在吸取了一些教训之后不会再 “对一些公司竖中指”。

但也正如 Phoronix 所言,无论如何 Linus 已经将新代码合并到 Linux 6.8 中。希望这只是 Intel Xe 驱动程序的一个 one-off issue,而没有更大的代码质量问题。

网络驱动支持

Linux 6.8中新的以太网驱动程序硬件支持包括Octeon CN10K设备、Broadcom 5760X P7、Qualcomm SM8550 SoC 和 Texas Instrument DP83TG720S PHY。蓝牙方面,新的驱动程序支持IMC Networks无线蓝牙设备。另外值得注意的是英特尔高速NIC驱动程序增加了对温度和时钟信息报告的支持,以及许多网络驱动程序中的其他随机改进。NVIDIA Mellanox以太网数据中心交换机现在无需重新启动即可享受固件更新。

Linux 6.8中删除了几个过时的WiFi驱动程序。新推出的WiFi支持包括Libertas 16位PCMCIA支持、Atmel at76c50x驱动程序、HostAP ISA/PCMCIA型802.11b驱动程序、zd1201 802.11b USB加密狗、Orinoco ISA/PCMCIA 802.11b驱动程序、Aviator/Raytheon驱动程序、Planet WL3501驱动程序以及RNDIS USB 802.11b驱动程序。

在WiFi协议方面,WiFi7工作仍在进行中,并且还进行了极高吞吐量(EHT) 的改进。

第一个Rus编写的网络PHY驱动程序

自Linux 6.1起,初始的Rust基础设施被添加到Linux内核中。此后为了使内核驱动程序能够用Rust编程语言编写,Linux内核已经合并了许多其他管道和内务管理工作。随着即将到来的Linux 6.8内核周期,第一个Rust网络驱动程序将被引入。最近一个“net-phy-rust”驱动程序被合并到了net-next.git分支。该驱动为phylib Rust绑定,包括了启用Rust编写的PHY驱动程序。AX88796B C驱动程序代码完全用Rust编程语言重写。

Rust ASIX PHY驱动大约135行Rust代码加上各种构建系统位。可以使用Kconfig的“AX88796B_RUST_PHY”选项启用此Rust ASIX PHY驱动程序。AX88796B 驱动程序用于支持X-Surf 100 AX88796B封装中的Asix Electronics PHY。AX88796B是一款100M快速以太网控制器,适用于从HVAC控制到安全系统和其他工业控制系统的嵌入式和工业应用。因此,这不是最令人兴奋的网络硬件(并且该硬件已经得到了C驱动程序的支持),但这个Rust PHY驱动程序是一个开始,并让在接口/绑定上滚动,以实现其他内存安全网络驱动程序将不断完善。

ReiserFS 作者在狱中就被 Linux 内核弃用发表评论

文件系统 ReiserFS 的作者 Hans Reiser 在2024年1月中旬通过信件交流的方式,在 Linux 内核邮件列表上发表了一篇评论。他在信中详细讲述了自己所犯的错误、ReiserFS 的历史、ReiserFS 的废弃以及他对 Reiser4 寄予的希望。

Hans Reiser 因 2006 年谋杀妻子入狱,现被关押在加利福尼亚州的监狱。这封信是他在狱中对 Fredrick R. Brennan 的回信,Fredrick 曾邀请他就从内核中删除 ReiserFS V3 的讨论发表一些看法。目前,这封信的内容已被允许转录并公开再分发。


Hans Reiser 对自己所犯的罪行进行了道歉,并向 ReiserFS 的用户道歉称:“因为我的犯罪和入狱,我没能实现那个梦想,他们也没能看到 Reiser 4 的任何语义改进。”

我不知道 Reiser 5 里有什么 —— 没有人告诉我,我也没资格要求大家不要让那些辛勤工作为用户构建漂亮文件系统的人受我声誉所困。我请你们体谅一下他们的感受。让他们的梦想摆脱我所造成的伤害吧。

在2022年2月的Linux内核社区正在讨论是否要弃用和删除ReiserFS。因为它已经有十多年没有活跃过了,而且在现代内核的生产用例中也不太可能再使用。提出删除 ReiserFS 的开发者表示,他希望改变内核基础设施,但 ReiserFS 的遗留在一定程度上对他的工作造成了阻碍。

目前看来,弃用 ReiserFS 的工作正在推进,但真正从主线内核中删除要等到 2025 年。上周五,SUSE 的 Jan Kara 提交了 v2 补丁,将 ReiserFS 标记为已弃用的文件系统,同时在 Kconfig 和挂载文件系统时发出警告,指出它将被删除。因此,ReiserFS 即将被正式弃用,并会在 2025 年从内核中删除。在现阶段,ReiserFS 与其他现代文件系统如 XFS、EXT4 和 Btrfs 相比,并没有任何明显的优势。

按照计划,用户有三年的时间来迁移到另一个现代文件系统,或者如果他们仍然需要以某种奇怪的方式使用 ReiserFS,可以坚持运行 2025 年前发布的 Linux LTS 内核。

Linus于2024年3月上旬在内核邮件列表宣布正式推出 Linux Kernel 6.8 稳定版。主要变化如下:
LAM/线性地址屏蔽的虚拟化支持
KVM 的 guest 优先内存支持
更新 Bcachefs 文件系统的基本在线文件系统检查和修复机制
对树莓派 5 使用的博通 BCM2712 芯片提供支持
基于 AMD ACPI 的 WiFi 频段 RFI 缓解功能
zswap、CephFS 等功能优化

此外,龙芯 LoongArch 架构在 Linux 6.8 内核已初步支持 Rust。该版本不是 LTS 版本,它的支持周期只有几个月,之后会被 Linux Kernel 6.9 版接替。目前 Linus Torvalds 已经开启了 v6.9 的合并窗口,预计在 2024 年 5 月中旬发布。

v6.9 弃用 ext2 文件系统驱动程序

在即将发布的 6.9 Linux 内核中,ext2 文件系统驱动程序将被标记为已弃用。EXT2(第二代扩展文件系统)是 Linux 内核所用的文件系统,最开始由 Rémy Card 设计用以代替 ext,于 1993 年 1 月加入 Linux 核心支持之中,至今已有30多年的历史。

Linux 开发人员 Michael Opdenacker 解释 ext2 被弃用的主要原因在于,即使文件系统是用 256 字节的 inodes(mkfs.ext2 -I 256)创建的,文件系统驱动程序也会坚持使用 32 位日期。因此驱动程序不支持超过 2038 年 1 月 19 日 03:14:07 UTC 的 inode 时间戳。

对于仍在使用 ext2 及其驱动程序,并且系统日期正确设置为截止日期之前最多 30 年的日期的用户,将收到此警告:
# mount -t ext2 /dev/sda1 /mnt
[  441.680685] ext2 filesystem being mounted at /mnt supports timestamps until 2038-01-19 (ox7fffffff)

由于无法正确支持 2038 年 1 月 19 日之后的时间戳。官方建议 ext2 用户升级到使用 ext4 驱动程序来访问其文件系统,ext4 文件系统驱动程序与 ext2 完全兼容。更多详情可查看此博客

Linux 蓝屏死机界面亮相

Linux v6.10 引入了一个新的 DRM Panic 处理程序基础设施,以便于在致命错误 (Panic) 发生时显示相关信息,这是活久见还是诚会完?

v6.10 还在开发之中,最新版本是 rc4,扩展 DRM Panic 支持的工作还在进行之中。未来在运行 Linux 6.10+ 的平台上,如果驱动支持 DRM Panic,那么就可以通过 echo c > /proc/sysrq-trigger 测试 Linux 版本的 “蓝屏死机(BSOD)”。


Red Hat 工程师 Javier Martinez Canillas 在 Mastodon 分享了一幅图像,展示了 Linux 版本的蓝屏死机界面。

AMD为Linux 6.11准备更多内核图形驱动代码 为RDNA4启用DCC

2024年6月下旬,通过 DRM-Next,社区为即将到来的Linux 6.11周期提交了更多 AMDGPU/AMDKFD 内核驱动程序变更。在7月中旬 Linux 6.11 合并窗口开始之前,DRM-Next 的功能工作已接近尾声,而最新的 AMD 拉取请求将继续为即将到来的 RDNA4 图形硬件和其他更改做准备。

AMD 为 6.11 提交的"新内容"包括一系列修复,从 SR-IOV 问题的解决到电源管理相关的修复以及其他各种缺陷的解决。此外,还对 GPUVM TLB 刷新进行了代码清理,增强了固件加载功能,解决了一些代码消毒器警告等问题。在为即将到来的 RDNA4 图形处理器做准备方面,DCN 4.0.1 Display Core Next IP 块也进行了修复。现在,针对 RDNA 4 硬件的 AMD GFX12 图形 IP 块也启用了三角色彩压缩(DCC)。这对于节省内存带宽和最终提高性能非常重要。

以上就是正在排队等待 Linux 6.11 的 AMD 内核图形驱动程序最新变更的摘要。这是在AMD 前几周围绕更多 RDNA 4 功能和 DRM-Next 中已经排好队的其他部分提出的拉取请求的基础上进行的。

资深 Linux Wireless 开发人员 Larry Finger 去世

长期为 wireless (WiFi)  驱动程序做出贡献的开发人员 Larry Finger 于 2024 年 6 月 21 日去世,他的妻子 Denise Finger 于周末在 linux-wireless 邮件列表上公布了这一消息。

根据介绍,Larry Finger 自 2005 年以来一直为 Linux 内核做出贡献,并见证了 1500 多个内核补丁被上传到 Linux 内核主线中。他最初的工作时致力于 Broadcom BCM43XX 驱动程序,多年来为 Linux WiFi 驱动程序做出了很多贡献。

Larry Finger 最近的贡献主要围绕 RTW88、RTW89、R8188EU、R8712、RTLWIFI、B43 和其他 Linux 网络驱动程序;部分归功于他的贡献,Linux wireless 硬件支持在过去二十年中取得了长足的进步。

Linux v6.10内核稳定版发布:为 RISC-V 架构添加 Rust 语言支持等

2024年7月中旬消息,Linus Torvalds 于 7 月 14 日发布邮件日志,正式发布 Linux Kernel 6.10 稳定版更新,在改善了硬件支持、修复 BUG 之外,还引入了多项新功能。简要汇总下LinuxKernel 6.10稳定版新特性内容如下:
移除对旧 Alpha CPU 的支持
支持 x32 子架构的影子堆栈(shadow-stack)
RISC-V 系统支持 Rust 语言
支持部分 Windows NT 同步原语(标记为 broken)
mseal() 系统调用
FUSE 文件系统子系统支持 fsverity
Landlock 安全模块支持 ioctl()
初步实现 DRM Panic 基础设施
改进 Ryzen APU 的 AMD ROCm/AMDKFD 支持

在改进硬件支持方面,Linux Kernel v6.10 主要改进支持 Radxa ROCK 3C 开发板、英特尔 Arrow Lake-H 处理器、联想 Thinkbook 13x Gen 4、联想 Thinkbook 16P Gen 5 和联想 Thinkbook 13X 笔记本电脑、华硕 ROG 2024 笔记本电脑和 Machenike G5 Pro 游戏手柄等。主要为内存密封(memory sealing)引入了 mseal() 系统调用,保护映射本身不被修改,并减少内存损坏问题。新版为 RISC-V 架构添加了 Rust 语言支持为,为 EROFS 文件系统添加了 Zstandard 压缩支持,以及为 x32 子架构带来影子堆栈支持,进一步完善 TPM 总线加密和完整性保护,并初步支持设置数据包转发控制协议(PFCP)过滤器。

v6.10 还为 PowerPC BPF JIT 编译器添加了 kfuncs 支持、用于将跟踪环缓冲区直接映射到用户空间的 ring_buffer 内存映射、用于在内核中控制 NFS 服务器的基于 netlink 的新协议、用于将策略应用到 ioctl() 调用的 Landlock 支持,以及对 FUSE 文件系统的完整性保护支持。

还引入了对 bpf_wq 的基本支持,让 BPF 程序能够在内核中使用等待队列,还为内核中的时间处理添加了 Rust 抽象,现在 AArch64(ARM64)系统支持 userfaultfd() 写保护功能。新增了 ntsync 子系统,用于为 Linux/Wine 游戏提供 Windows NT 同步原语,以及用于 32 位 ARCv2 处理器的 BPF 即时编译器和用于 dm-crypt 设备映射器的新 high_priority 选项,用于在处理过程中设置高优先级工作队列,这可能会提高大型系统的性能。

v6.10 对 Rust 的支持已更新至 Rust 1.78.0,ARM 架构获得了对 Clang CFI(控制流完整性)和 LPAE 特权访问永不支持的支持,OverlayFS 文件系统获得了使用 O_TMPFILE 选项创建临时文件的能力,还有一个名为“init_mlocked_on_free”的新启动选项,可在释放时将锁定在 RAM 中的任何页面清零。

在改善硬件支持方面,Linux v6.10 主要改善支持 Radxa ROCK 3C 开发板、英特尔 Arrow Lake-H 处理器、联想 Thinkbook 13x Gen 4、联想 Thinkbook 16P Gen 5 和联想 Thinkbook 13X 笔记本电脑、华硕 ROG 2024 笔记本电脑和 Machenike G5 Pro 游戏手柄等。还将通过在现代 x86_64 CPU 上更快的 AES-XTS、可大幅提高分区设备性能的分区写入插件、通过 io_uring 大幅提高发送零拷贝性能,以及提高 OCFS2(Oracle Cluster File-System v2)文件系统的写入性能等等。

另外开启 6.11 合并窗口。更多变化查看 KernelNewbies 6.10 页面。

Rust for Linux 项目遭遇挫折

1、Rust for Linux 内核维护者之一因“非技术原因”退出团队

2024年9月上旬消息,Rust for Linux 内核维护者之一、微软工程师 Wedson Almeida Filho 在 Linux 内核邮件列表上写道:我本人将退出 Rust for Linux 项目的维护者团队。之所以决定退出项目,是因为在过去四年的工作当中,我发现自己的精力和热情已经被严重消磨,越来越抗拒回应那些跟技术无关的废话。所以这份任务,最好是留给那些仍然抱有这份热情的成员。 致 Rust for Linux 团队:感谢大家,你们最棒。很高兴能跟各位一起工作,我们共同讨论技术问题、寻找解决健全性漏洞的方法等等产,这些都是我宝贵的回忆和人生经历。很幸运能够与这样一个才华横溢、友好和善的团队携手并进。 祝愿这个项目一切顺利。 我坚信内核开发的未来在于内存安全语言。我不是那种很有前瞻性的人,但如果 Linux 没法把这项优势内化己用,我担心其他内核终将像取代 Unix 那样冲击 Linux。

Wedson Almeida Filho 是一位微软工程师,在过去几年中为 Rust for the Linux 内核代码做出了大量贡献。Wedson 开发了许多 Rust Linux 内核功能,甚至还主持将 EXT2 文件系统驱动程序移植到了 Rust。但他已经受够了,现在正退出 Rust for Linux 的工作。

值得注意的是,该电子邮件还包含一个 YouTube 视频链接,该视频是 Filho 在 2024 年 Linux 内核峰会上发表的演讲,在演讲中,他因在内核中使用 Rust 而遭到一些观众的强烈反对。观众中的批评者认为,Rust 的集成将给 C 语言开发者带来过度负担,他们将被迫学习一门新语言并保持与 Rust 绑定的兼容性。

此外,一些开发人员还对 Rust 绑定的稳定性以及对 C 代码进行更改时可能出现的故障表示担忧。然而,Wedson 和其他支持将 Rust 纳入内核的人认为,这些担忧被夸大了,Rust 可以与 C 共存,而不会损害内核的稳定性。他们认为,Rust 的好处(尤其是其内存安全功能)超过了集成带来的挑战。关于将 Rust 纳入 Linux 内核的争论凸显了开源社区在维护稳定的代码库和拥抱创新之间的更广泛的矛盾。

虽然一些开发人员看重 C 的熟悉度和可靠性,但其他开发人员认为采用 Rust 等更新、更安全的语言对于 Linux 内核的长期健康和安全至关重要。这场辩论的结果可能会对 Linux 和更广泛的开源生态系统的未来产生重大影响。

2、Linux 社区的反应

Linux 社区中就是否将 Rust 纳入 Linux 内核展开了很多激烈的争论。在国外知名技术社区平台 Reddit 上,用户关于这个问题的讨论十分激烈。以下是支持和反对在 Linux 内核中使用 Rust 的论据。

支持将 Rust 纳入 Linux 内核的论据:提高内存安全性:Rust 的内存安全功能可以帮助防止 C 和 C++ 代码中出现的大量错误和安全漏洞。这在像 Linux 内核这样庞大而复杂的代码库中尤为重要,因为即使是技术娴熟的程序员也难免会犯错。此外, 谷歌的数据 表明,在现有代码库中使用 Rust 代替 C 和 C++ 可以减少高严重漏洞的数量。

吸引新的开发者:将 Rust 纳入内核有助于吸引那些更熟悉现代语言的新开发人员,他们可能会因为使用 C 语言的难度和复杂性而放弃使用。这也是 Linux 创建者 Linus Torvalds 批准将 Rust 纳入内核的主要原因之一。

反对将 Rust 纳入 Linux 内核的论据:内核开发人员对变更的抵制:许多长期从事内核开发的人员不愿意学习一门新语言,尤其是当他们没有明显需要学习新语言时。他们认为,他们宁愿花时间学习更多关于内核的知识,也不愿学习一种新的方式来完成他们已经知道如何做的工作。这种抵制表现为对于那些在内核中提倡使用 Rust 的人的敌对和不专业的行为,例如对 Wedson Almeida Filho 的态度。

维护 C 和 Rust 代码之间兼容性的难度:确保对 C 代码的更改不会破坏 Rust 代码,反之亦然,是一项重大挑战。在内核中缺乏全面的自动化测试的情况下,这尤其成问题。对 Rust 成熟度的担忧:一些内核开发人员担心 Rust 还不够成熟,无法用于像 Linux 内核这样重要的项目。他们担心该语言及其工具仍在快速发展,依赖它们可能会导致不稳定和不可预见的问题。

一位观看了 Wedson 和 Kent 在会议上的演讲完整视频和这次会议的其他一些视频的 Reddit 用户认为,Linux 内核开发人员看起来非常糟糕。“看起来他们正在现场对演讲者进行嘲讽,完全不关心他们是如何进行 30 分钟的演讲的,那场会议看上去让人很不舒服。他们对待 Wedson 显然是不尊重的,而且是当面直说的,所以我认为不应该责备 Wedson 辞职。我读了一些关于 Rust for Linux 的评论,Linux 内核似乎是一个特别有毒的工作环境,里面充满了那种自己没什么成熟经验,但却仍然自以为是的工程师们。”

3、为什么 Linux 内核要反抗 Rust?

从上述 Reddit 讨论帖和 Wedson Almeida Filho 的辞职邮件中可以似乎看出,现在还有很多人反对将 Rust 纳入 Linux 内核。这种抵制并不一定源于对语言本身的厌恶,而是由多种因素共同导致的,其中许多因素反映了软件开发中更广泛的问题。其中一些是技术问题,但更多的则是非技术上的问题。

从技术角度而言,反对将 Rust 纳入 Linux 内核的原因集中在两点上:第一是维护负担和 API 稳定性,第二是复杂性和“不安全”难题。人们反复担心的是保持 C 和 Rust 之间兼容性的实用性。内核开发人员(其中许多人都是资深的 C 专家)表示,他们担心需要承担额外的责任,以确保他们的 C 代码更改不会无意中破坏 Rust 组件。鉴于内核中的自动测试有限,这一点尤其重要。

此外,一些开发人员认为,为了弥合 Rust 严格的安全规则与内核级编程固有复杂性之间的差距,可能需要在 Rust 中过度使用“unsafe”关键字。这被视为可能会破坏 Rust 旨在带来的安全优势。

非技术原因是更深层次的开发者之间的文化冲突。在 Reddit 和 Hacker News 上,都有用户提到 Wedson 的退出是一个非常典型的“旧团队”与“新团队”之间的分歧。这种声音强调:

“一个新团队认为他们将重写一切并让世界变得更美好。而老团队多年来则是一直埋头苦干,他们对代码了如指掌,并经过艰苦的调试,才让系统进入目前的状态(在这种情况下,这是一个非常成功的状态,因为 Linux 文件系统几乎将所有数据存储在云中),他们更加脚踏实地。新团队思考问题的方式可能过于简单,让老团队感到不被尊重。(这种明显的不尊重可能是你听到这种咄咄逼人的语气的原因。)这是一种非常典型的文化冲突。”

此外,想将 Rust 纳入到 Linux 也面临着一些变革阻力和学习曲线难题。许多长期的内核维护者表示不愿意花时间和精力学习一门新语言,尤其是如果他们已经成功使用 C 多年,这种抵触情绪随着 Rust 的责任落在他们身上而加剧。

更糟糕的是,一些内核开发人员和 Rust 拥护者似乎在开发理念上存在根本分歧。内核社区重视稳定性、成熟的方法论以及对复杂代码库的深入理解,他们可能会认为 Rust 的严格规则和对内存安全的重视是一种额外的限制,而不是一种好处。

Reddit 讨论中的一些评论暗示,人们认为 Rust 支持者是“精英主义者”,或者对 C 开发人员的专业知识不屑一顾。再加上长期使用 C 语言的开发人员和那些更熟悉新语言的开发人员之间可能存在的代沟,这进一步加剧了 Rust 融入具有完善规范和等级制度的社区的难度。

然而,不得不提的是,并非所有 Linux 内核开发人员都反对 Rust。许多人看到了它的潜在优势并支持将其纳入。但是,上述观点凸显了技术、社会和哲学因素的复杂相互作用,这些因素导致了 Rust 在 Linux 内核团队内部面临的抵制。

4、Rust 在 Linux 内核中的未来

在抵制和支持两种声音兼而有之的情况下,Rust 在 Linux 内核中的未来将何去何从?在近日 Verizon 开源官 Dirk Hohndel 与 Linux Torvalds 的一次关于 Linux 的现状以及未来发展方向的公开对话中或许能窥见些端倪。

在这次公开对话中,Hohndel 与 Torvalds 谈到了如何将 Rust 语言引入 Linux。Torvalds 对 Rust 的应用速度未能如预期般加快感到失望。“我原本指望着更新速度会更多,但问题在于不少老一代内核开发人员更习惯于使用 C 语言,而不太熟悉 Rust。他们不太愿意学习一种在某些方面与老办法截然不同的新语言。因此,Rust 的普及受到了一些阻力。”

除此之外,Torvalds 还评论道,“另一个原因在于,Rust 自身的基础也并不是十分牢靠。”最后,Torvalds 表示自己并不关心云和 Kubernetes 这类新技术。“内核才是唯一需要关注的重点。”

Linux Kernel 6.11正式发布

Linus Torvalds 于2024年9月中旬在内核邮件列表正式发布了 Linux Kernel 6.11,以及开启 6.12 合并窗口。
v6.11 主要新特性包括:
io_uring 子系统支持 bind () 和 listen () 操作,
对实时内核减少延迟的新锁定机制
减少文本占用错误信息 ETXTBSY
支持用 Rust 开发块驱动程序
支持块层的原子写入操作
专用 bucket slab 分配器加固内核防御堆喷射(heap spraying)攻击
getrandom () 的 vDSO 实现,等等。

此外,Linux 6.12 有望成为新的长期支持版本 (LTS)。

Linus:C 很简单,但易犯错,而 Rust 不是

2024年9月16日,在维也纳举行的 Linux 基金会开源峰会上,Linus 谈到了关于 Rust 和 C 语言的争论。


“C 语言,归根结底,是一个非常简单的语言。这是我享受 C 语言的原因,也是很多 C 语言程序员喜欢它的原因。也正因为它简单,所以也非常容易犯错;而 Rust 不是”。在与 Verizon 开源部门负责人 Dirk Hohndel 的现场对话中,Linus 对 Rust 的安全性予以了肯定。

将 Rust 引入 Linux 内核已经成为一个热门话题。2022 年,开发者们就这门语言进行了争论,一些人将 Rust 的内存安全特性称为对多年来内核工作的 “侮辱”。9 月初,Rust for Linux 项目的一位维护者辞职,称对 “非技术性的胡说八道” 感到沮丧。这在技术圈引起了讨论。

Linus 表示,不理解为什么 Rust 会成为如此有争议的话题,并笑称这让他想起了过去人们关于 vi 和 Emacs 编辑器的争论(补充一下:vi 和 Emacs 的争论可以追溯到 20 世纪 70 年代,并且至今仍在继续)。

“Rust 和 C 的讨论几乎带有宗教色彩。”Linus 直言,争论有时会变得激烈,甚至可以说是恶毒。但他认为在这些关于 Rust 的争论是积极的,因为它激发了讨论,表明有人在乎。现在人们都在谈论 “Rust 集成失败了”,Linus 认为,要得出这一结论还为时尚早,毕竟才做了几年。何况他并不认为该项目会失败。

一个月前,在香港举行的 Linux 基金会开源峰会上,Linus 就曾公开表示,Rust 在 Linux 内核项目中的采用速度太慢了。

一方面,因为很多资深内核开发者都已经习惯了 C 语言,对 Rust 并不熟悉。况且 Rust 以学习曲线陡峭著称,他们没有什么兴趣学些一门新的语言。另一方面,Rust 的基础设施本身还不够稳定。确实如此,与 C 语言相比,Rust 的生态系统还相对年轻,而 C 语言的生态系统已经发展了几十年,拥有大量稳定、经过时间检验的库和工具。

虽然这么说,但也并不影响 Linux、Windows、Android 三大操作系统积极探索和引入 Rust 语言,以利用其在内存安全和并发编程方面的优势。为什么都三大操作系统都看好 Rust,它是怎么实现内存安全的?以至于谷歌甚至哭着闹着要脱离 C/C++。在操作系统之外,Rust 也将取代 C/C++ 吗?有人就认为,Rust 适合写内核级别的代码,但并不是适合业务开发,因为它不够高效,不够灵活。

Linus Torvalds谴责硬件厂商漏洞不断:称操作系统开发者没有义务为其善后

Linux 的创造者 Linus Torvalds 在2024年10月中旬对英特尔、AMD & 英伟达(NVIDIA)等公司的硬件漏洞感到"沮丧",声称制造商是漏洞背后的原因。他表达了行业内习惯于让操作系统开发者去善后的不满,主要是在与外部因素(可能是AMD和英特尔等CPU公司)相关联的时候。他最近一直在积极地修复 Linux 内核,因为据报道,内核出现了错误和崩溃。据他称,这一次他对为了迎合硬件制造商的过失而修改开源内核的做法表示不满。

Torvalds 特别指出了 Intel 首次推出的支持 LAM(线性地址掩码)的最新 CPU,以下是他在 Linux 内核邮件列表公共收件箱中的发言(via kernel.org):老实说,我已经受够了漏洞百出的硬件和完全理论化的攻击,这些攻击从未实际应用过。因此我认为这次我们要反击硬件人员,告诉他们这是他们**该死的问题,如果他们连"是"或"否"都懒得说,那我们就坐以待毙吧。因为该死的,我们应该把责任归咎于硬件,而不是随便拿出一个糟糕硬件"就说"哦,但这**可能是个问题"。 - Linus Torvalds

要通过修改来解决内核中的问题会麻烦,而这很可能与"硬件人员"及其实现有关。就 LAM 而言,这一特殊功能是通过采用"基于指针的实现"来确保内存完整性的;然而,这种技术却导致了频繁出现的名为 SLAM 的投机攻击,而这显然正是目前困扰 Torvalds 的问题所在。英特尔公司的一位工程师对 LAM 问题做出了回应,声称该技术本应被禁用,直到找到修复方法为止,但事实并非如此。他认为LASS(线性地址空间隔离)最终可以避免 SLAM 攻击,但该团队暂时还没有推出修复方案。

此前曾报道过 Linus Torvalds 如何对 AMD 的 fTPM 表示不满,并呼吁该公司禁用该功能,声称它不应该在运行时使用。 因此,Torvalds 擅长公开指责公司,这也是他以发表有趣言论而闻名的原因。

v6.12 正式发布:真实时内核来了

Linus Torvalds 于2024年11月中旬在邮件列表宣布推出 Linux Kernel 6.12。更新内容如下:
1.对'PREEMPT_RT'(Real-Time Linux) 补丁的主线支持,显著提升了实时应用的性能,通过使内核进程可抢占 —— 有效地实现了正确的实时计算
2.引入新的 sched_ext 调度程序,其文档描述为 “行为可以通过一组 BPF 程序定义的调度器类 ——BPF 调度器”
3.在 Linux 内核的 panic 蓝屏界面添加包含错误代码信息的二维码

图形显示方面还包括更新内核后及显卡驱动程序后终于能够显示英特尔显卡的风扇转速、支持英特尔 Panther Lake HDMI 音频以及默认启用 Intel Xe² Lunar Lake 和 Battlemage GPU,因此用户若在搭载 Intel Core Ultra 200V 系列处理器的笔记本电脑上安装 Linux 系统将为这些显卡提供开箱即用支持。

其他新功能还包括对 EROFS 文件系统的文件支持挂载、对 LoongArch KVM 虚拟机提供 PMU 支持、对 RISC-V 上的基于 ACPI 的中断控制器枚举提供支持。v6.12 还增加了在 Android 上作为受保护客户机运行的支持以及对性能和一系列新互联 PMU 的支持。

新版内核在硬件方面的支持更新也非常多,例如新版驱动程序和更新后的驱动程序都提供更好的硬件支持,新增的硬件支持包括 Marvell xSPI、MTK7981、Microshop PIC64GX、NXP i.MX8ULP、Rockchip RK3576、Realtek RTL 9054、RTL 9068、RTL 9075、RTL 9071 等等。

对消费级设备的支持还包括对基于 Arm64 架构的 Surface 设备的支持、对 LG 笔记本电脑的操作区域支持、对 Dell 笔记本电脑的电池充电设置更改支持、对 ASUS Vivobook 风扇配置文件支持、对高分辨率滚轮滚动等新硬件功能的支持。

文件系统则包括对 EXT4、Btrfs、exFAT、FUSE、F2FS 和 Bcachefs 带来各种改进,提升稳定性和易用性等。

文件系统 ReiserFS 将从v6.13内核中被移除

随着 Linus Torvalds 的正式决策,ReiserFS 文件系统将在即将发布的 Linux v6.13 内核中被移除。这一决定不仅标志着这项技术正式退出历史舞台,也为它画上了最后的句号。曾经辉煌一时的 ReiserFS,如今更像是计算机科学历史中的脚注,值得我们回顾和铭记。随着 Linus 在2024年11月下旬合并了提案,正式决定在即将发布的 v6.13 内核中停止支持 ReiserFS 文件系统,这项技术可以说已经从实用工具转变为历史文物,更适合出现在计算机科学教材里了。

起源与辉煌

技术的诞生
ReiserFS 诞生于 2001 年,由 Hans Reiser 和他在 Namesys 的团队开发,并随 Linux 2.4.1 内核发布。作为一种开创性的日志文件系统,ReiserFS 专为 Linux 优化,其设计目标是:
1.提升小文件的处理性能
2.高效管理元数据

相较于当时流行的 ext2 文件系统,ReiserFS 在速度、扩展性和可靠性上有显著提升。这使其成为首批被广泛应用于 Linux 的日志文件系统之一。

辉煌的黄金时代
2001 至 2006 年间,ReiserFS 一度是 SUSE Linux 的默认文件系统,广泛应用于服务器和桌面系统。它尤其擅长处理大量小文件,使其在特定应用场景下表现出色。例如,数据库和邮件服务器中对元数据密集型操作的需求,都能从中受益。此外,ReiserFS 的创新性数据存储与分配方法也为后续的文件系统设计提供了重要参考。

从巅峰到衰落

命运的转折点
2008 年,ReiserFS 的命运发生了巨大转折:Hans Reiser 因法律纠纷被捕入狱,这不仅导致 Namesys 公司解散,还让文件系统的开发与维护陷入停滞。从那时起,ReiserFS 只能依靠少数开源社区爱好者维持,逐渐被更先进的文件系统取代。

技术挑战与竞争压力
随着时间推移,ReiserFS 的技术优势被逐渐淘汰:
1.ext4 和 Btrfs 等新一代文件系统提供了更高的性能、更强的功能和活跃的开发支持。
2.ReiserFS 无法解决关键技术问题,如 2038 年问题(与时间戳溢出相关)。

最终,ReiserFS 在 2022 年的 Linux v5.18 中被正式标记为“弃用”,退出已经成为不可避免的结局。

Linux v6.13 内核:为 ReiserFS 划上句号
Linus 宣布 ReiserFS 将从 2025 年初发布的 v6.13 内核开始被完全移除,这一决定为这项技术的生命周期画上了句号。目前几乎没有人在生产环境中使用 ReiserFS。即便如此,使用内核早期版本的用户依然可以继续运行它。但为了更好的支持与安全性,建议尽快迁移到现代文件系统,如 ext4、Btrfs 或 XFS。

ReiserFS 的技术遗产:虽然 ReiserFS 即将退出历史舞台,但它的影响力不容忽视。作为早期日志文件系统的先锋,它在元数据处理、存储分配等方面的创新推动了现代文件系统的设计与发展。ReiserFS 的出现不仅提升了 Linux 的可用性,也证明了开源社区技术创新的力量。

v6.13 将有功能监控自系统启动以来挂起的任务数量

Linux 6.13 在2024年12月初的开发动态显示,该版本内核将包含一个新的挂起任务计数器。该特性通过新增的 /proc/sys/kernel/hung_task_detect_count 文件来实现,它将统计自系统启动以来发生的挂起任务警告数量。这对于 Linux 服务器管理员来说是一个有用的健康指标,可以帮助他们判断是否存在软件或硬件问题所导致的大量意外挂起任务。

发送补丁并提议使用 “hung_task_detect_count” 计数器的 Lance Yang 解释道:此补丁集添加了一个计数器,即 hung_task_detect_count,用于跟踪检测到挂起任务的次数。在我看来,挂起任务是一个关键指标。目前,我们通过定期解析 dmesg 来检测它们。但是,这种方法不像使用计数器那样方便用户使用。有时,NIC 或硬盘驱动器的短暂问题会迅速将 hung_task_warnings 降至零。如果没有警告,我们必须直接访问节点以确保不再有挂起任务并且系统已恢复。毕竟,仅靠平均负载无法提供清晰的图像。

一旦此计数器到位,在高密度部署模式中,我们计划将 hung_task_timeout_secs 设置为较低的数字以提高稳定性,即使这可能会导致误报。然后我们可以设置一个基于时间的阈值:如果挂起任务持续时间超过此持续时间,我们将自动将容器迁移到其他节点。根据过去的经验,这种方法可以帮助避免许多生产中断。此外,就像其他已经有计数器的重要事件(如 OOM)一样,拥有一个用于挂起任务的专用计数器很有意义;v6.13 的非 MM 补丁拉取请求还包括对资源管理代码的清理,以及完成了 NILFS2 文件系统的对开本转换。这些变化的目的是提高内核的性能和稳定性。

v6.12 正式晋升为 LTS 内核

Linux 稳定版维护者 Greg Kroah-Hartman 于2024年12月初正式指定 Linux v6.12 为2024年的长期支持(LTS)内核版本。kernel.org 文档也进行了更新,v6.12 正式成为继2023年的 Linux v6.6 LTS 系列之后的最新 LTS 版本。

目前,v6.12 LTS 状态标注的预计生命周期结束(EOL)日期是 2026 年 12 月:距离现在只有两年时间,与 Linux 5.10 / 5.15 / 6.1 / 6.6 LTS 系列的生命周期结束日期相同;v6.12 LTS 的期限有可能会延长到 2026 年 12 月之后,但这取决于硬件/软件供应商、测试人员和广大开源社区的支持程度,他们是否会继续积极使用 v6.12 LTS 内核,并帮助测试该系列的新补丁、审核 v6.12.xx 候选发布版本等。

v6.12 成为 LTS 内核并不令人意外。通常情况下,特定日历年的 LTS 内核是该年的最后一个主要版本,即 2024 年的最后一个主要版本,它在11月首次稳定发布,v6.12 提供了许多强大的功能。

v6.1 LTS 额外延长一年支持

Linux 内核维护者 Greg Kroah-Hartman 在2024年12月中旬决定将 Linux 6.1 LTS 的计划支持周期从四年延长到五年 —— 持续支持到 2027 年年底。

v6.1 是 2022 年发布的长期支持内核版本 (LTS),原计划是在 2026 年底之前提供维护。现在社区对这个内核版本的认可和使用以及测试方面的帮助,Greg KH 决定再延长一年的支持时间。因此 v6.1 LTS 将更新维护到 2027 年底。v6.12 作为今年的 LTS 版本,计划支持到 2026 年底,与去年的 Linux 6.6 LTS 保持一致。

v5.15 LTS 和 v6.10 LTS 也将支持到 2026 年底,而 Linux 5.4 LTS 预计将在明年年底停止支持。这些日期只是初步计划,如果能得到足够的支持和投入资源,可能会延长支持时间 —— 就像 v6.1 LTS 一样。就在本月,v4.19 LTS 达到了 EOL 状态。

v6.14 将允许 VirtualBox 客户机支持 ARM64 架构虚拟

2025年1月下旬消息,Linux v6.14 内核将支持为 ARM64 Linux 虚拟机(VM)构建 VirtualBox 客户机驱动程序。作为 VFS misc 拉取请求的一部分,v6.14 将在 ARM64 上启用对 VirtualBox Guest 的初始支持。这相当于一个 Kconfig 更新,允许 VirtualBox Guest 驱动程序支持为 ARM64 构建,而不是仅限于 x86/x86_64 内核。

现 Oracle VM VirtualBox 已开始在 ARM64 主机(如苹果 M3/M4 设备)上运行,因此出现了这一变化。随着对 ARM64 VirtualBox 虚拟机管理程序的实际支持,上游客户机内核驱动程序现在也应允许为 ARM64 内核构建。这一变更允许 Linux 内核构建启用 ARM64 上的 “VBOXGUEST ”选项,以支持 VirtualBox Guest 集成,还允许启用 “VBOXSF_FS”,以实现主机和客户机之间的共享文件夹集成。VirtualBox Guest ARM64 Linux 支持通过使用运行最新 VirtualBox 上游软件的 Apple MacBook Pro 和 Linux Guest 虚拟机进行测试。该支持已作为 VFS misc 拉取请求的一部分提交给 Linux 6.14。

Linux 内核新补丁调整 AC 电源插拔行为,向 Windows 看齐以提升硬件兼容性

2025年2月消息,AMD 工程师 Mario Limonciello 向 Linux 内核提交了一系列补丁,旨在调整系统在 s2idle(挂起到空闲)状态下的 AC 电源插拔行为,使其更贴近 Windows 11 的逻辑。这一改动主要针对笔记本电脑、手持游戏设备(如 Steam Deck 同类产品)在休眠时因电源状态切换导致的兼容性问题,尤其是此前曝光的 Legion Go S(搭载 AMD Ryzen Z2 芯片)的固件级故障。

为何需要 “模仿” Windows?
当前,Linux 与 Windows 在 s2idle 状态下的电源行为存在关键差异:
1.Windows:插入或拔出 AC 电源时,系统会完全唤醒,若后续无用户操作则重新进入睡眠。
2.Linux:AC 事件仅触发短暂唤醒后立即重回休眠,可能导致硬件固件因快速状态切换出现异常(例如某些设备无法正确处理快速进入/退出低功耗模式)。

Limonciello 指出,由于 OEM 厂商通常基于 Windows 进行硬件验证,Linux 的差异行为易暴露底层固件缺陷。新补丁通过记录休眠前的电池状态,并在 AC 事件后对比状态变化,决定是否彻底唤醒系统,从而减少 “兼容性陷阱”。

技术细节:唤醒机制与能耗监控

1.唤醒逻辑重构
补丁在 ACPI 电池驱动中新增 suspend_state 字段,休眠时保存当前电源状态(如是否充电)。若唤醒后检测到状态变化(如从充电变为放电),则触发系统完全唤醒,而非立即休眠。

2.能耗统计透明化
新增 /sys/power/suspend_stats/last_sleep_energy 文件,以毫安时(mAh)为单位记录上次休眠周期的电池消耗量,方便用户空间工具分析功耗问题。

争议与用户控制
尽管新行为默认启用,但开发者社区对其适用场景存在分歧。例如,若笔记本合盖时连接电源,是否应强制唤醒?Limonciello 认为,这与用户外接扩展坞的场景需求一致,但用户仍可通过禁用 ACPI 电池设备的 power/wakeup 属性恢复旧逻辑。

影响与未来展望
此次调整尤其利好搭载 AMD 芯片的设备,但惠及所有支持 s2idle 的 x86/ARM 平台。随着 Linux 在掌机市场的渗透(如 Steam OS 设备),此类优化将显著提升用户体验。此外,补丁的 “Windows 兼容性驱动” 思路或成为未来硬件支持的新范式,减少厂商因生态差异对 Linux 的适配成本。

Linux 在电源管理领域的 “向 Windows 学习”,并非妥协,而是以用户体验为优先的务实选择。这一补丁不仅修复了长期存在的兼容性痛点,也为开源生态与 OEM 厂商的协作提供了新思路。未来,类似 “求同存异” 的优化或成常态,进一步模糊两大操作系统在硬件支持上的体验边界。