Linux 6.0-rc1 发布,Linus “也可以称之为 5.20 版本”


Linux 6.0 的第一个候选版本已发布,Linux 6.0 内核将在两个月内稳定下来。

Linux 6.0 带来了超百万行代码,这些代码主要来源于 AMD GPU 和英特尔 Habana Labs Gaudi2 支持代码。下面是该版本一些重要的变更:

  • 合并大量 char/misc 代码,提供 Gaudi2 支持
  • 引入 F2FS 低内存模式,用性能减少内存占用 
  • 为 LoongArch 架构启用 PCI 和其他功能支持
  • 为 Arm64 添加 UEFI 镜像内存和 ACPI PRM 支持
  • 将其 H.265/HEVC 用户空间 API 提升到稳定状态
  • 大量英特尔 DG2/Alchemist 和 AMD RDNA3 图形改进

但一些期待已久的内容,比如 Rust For Linux 的正式补丁尚未合并,增强性能的 MGLRU 工作也没有在这个版本中出现……也许会在 Linux 6.1 中合并。Linus Torvalds 还注意到最近出现的一些 Linux 内核崩溃,这些崩溃似乎是因为 VirtIO 合并,并且已经在解决中。

有关该版本的详细改动,可在 Linux 6.0-rc1 公告中查看。

有意思的是,Linus 在发布公告中认真地解释了采用 Linux 6.0 版本号的原因,还提到了中国开发者对“5.20 ”版本号的建议:

尽管主要版本号发生了变化,但这个版本并没有一些革新性的内容。“分层”编号系统的唯一原因是让版本号更容易记住和区分。这就是为什么每次在次版本号达到 20 左右时,我更喜欢增加主版本号,并重置次版本号的数字。

在我决定把这个内核称为 6.0之后,一些中国的开发者指出“5.20”是更好的版本号。如果你愿意把它叫做“Linux 5.20”,也可以继续这么叫。因为内核版本号真的完全是虚构的,没有任何内在的意义。

最近几周 Linux 内核邮件的讨论一直在交替使用 5.20 和 6.0 两个版本号,直到 Linus 最终决定采用 6.0 。


相關推薦

2022-10-14

Spring Framework 6.0 发布了首个 RC 版本。 发布公告写道,Spring Framework 6.0 作为重大更新,目前 RC1 要求使用 Java 17 或更高版本,并且已迁移到 Jakarta EE 9+(在jakarta命名空间中取代了以前基于javax的 EE API),以及对其他基础设施

2023-04-17

读 Usenet、同时运行许多 xeyes 程序副本。因此,1.0 版本的发布被提上了日程。 1995 年,Linus 和 Lars 在大学上了一门软件工程课程,其中主要包括一个建立在 Linux 之上的大型实践项目。Lars 表示,他当时出于一些经验坚持要使用

2021-12-13

的事情。比如,自由软件基金会要求遵守 GPLv2 的人们在发布自己的代码时候必须兼容它的任何未来版本(Any future version),向 Linus 施威;又比如,在劝说 Linus 采用 GPLv3 时某些不诚实的言论。 “自由软件基金会暗地里做的那

2022-10-12

如果 Linux 内核下一个版本的发布时间推迟,甩锅给 Linus 吧 : ) Linux 6.1 的合并窗口目前处于开启状态。在刚刚过去的周日,一名内核维护者向 Linus Torvalds 询问是否错过了一个合并请求。 对此,Linus 回应称该合并请求仍

2022-09-18

,这并没有发生。我不会断言它会在 6.1 版本进入(10 月发布)。但是,它已经持续了足够长的时间,我们只需要合并它,因为不合并它并没有什么帮助。而且这将会发生。当然,有些人仍然认为我们可能会遇到问题,但如果两

2022-11-30

假期之前完成他们的开发工作。 Linus 在刚刚过去的周末发布了 Linux 6.1-rc7。他在邮件中表示,本以为感恩节会影响内核的开发工作,但现实情况与他的判断相反——假期并没有减缓开发进度。因此,Linus 决定再为 Linux 6.1 发布一

2021-12-27

Linux Professional Institute 董事会主席 Jon Maddog Hall 在 Archive.org 上公开了 Linus Torvalds 在 1994 年发表的主题演讲录音。 根据 Jon Maddog Hall 的介绍,在 1994 年 DECUS 大会期间,当时他看到还没认识的 Linus 帮助 DECUS UNISIG 主席 Kur

2023-05-02

dress Masking :线性地址掩码) 功能,终于合并到  Linux 6.4 中。 英特尔线性地址掩码 (LAM) 允许软件将 64 位线性地址的未转换地址位用于元数据,可用于用户空间内存清理和标记等元数据的多种用途。 它的本质上类似

2022-09-30

成共识,他们不打算将已有的内核用 Rust 重写,只专注于可以用 Rust 编写的新代码。具体来讲,他们集中讨论了 Linux 内核对 Rust 的支持可能涉及到的三个方面:内核中现有的 API、架构支持,以及 ABI 与内核的兼容性问题。 2021

2022-10-26

些工作没什么价值。 Linus 指出,既然 i486 已经被视为可以在博物馆里展示的展品,不如让它们运行博物馆版本的内核。由于 Linux 6.1 可能会成为今年的 LTS 版本,因此 Linus 希望在 6.2 中继续推进该工作,移除对旧的 i486 的支持

2023-05-10

,这样就不会污染共享的 x86 代码,也不会误导用户 LAM 可以在 32 位环境中工作。 修复地址掩码中的 Bug(这不重要,只是完全删除了错误的代码)。 几个简单的清理,并添加了关于 access_ok() 规则的注释。 Linus 重新编写了

2022-12-21

有些太晚了? ... 整个 LAM  功能不是特定于 mm ,它可以轻松影响每个线程。 想象一下,有一个设置,其中一些线程使用标记指针,而一些线程不使用。例如,地址的高位可能包含一个仅在虚拟机中使用的标签,甚至可以

2023-07-03

更多的是忙于监督上游的内核开发社区、审查代码、管理发布,并在邮件列表中进行讨论。不过近日,他就为 Linux 6.5 进行了将近 500 行的 code rework ,以改进用户模式的堆栈扩展代码。 他在合并报告中解释称: 这修改了我

2022-02-28

更直接的修复如块级变量声明。但 C89 不支持,而 1999 年发布的 C99 标准支持。所以 Linux 内核也许是时候转向使用 C99 标准了。 Linus 说到,内核代码一直停留在 C89 的原因之一是编译器 gcc 的旧版本会出现奇怪的问题,导致初始