泰晓资讯·9 月 / 第一期 / 2024

“泰晓资讯”，广泛报道 “Linux/开源” 业界资讯。欢迎广大读者投递相关资讯来源和素材，本站将进一步收集整理后发布给大家。

Linux 内核最新消息

和上周的 Linux 6.11-rc5 一样，由于 Linus Torvalds 上周末在国外旅行，Linux 6.11-rc6 提前半天发布。Linux 6.11-rc6 为内核带来了更多修复，其中包括：为 Bcachefs 实验文件系统提供了更多修复，一个重要的针对 Intel Arrow Lake graphic 的修复，为更多即将推出的 AMD Zen 5 型号做的准备工作，一个针对 AMD Preferred Core 的修复，以及整个庞大内核代码库中的其他常规修复。

Linus Torvalds 在他的公告中说：

“I’m still in an unusual timezone, but next week everything should be back to normal.

Anyway, it’s definitely well past Sunday afternoon here, and thus time for the weekly rc release.

Things look pretty normal, although we have perhaps unusually many filesystem fixes here, spread out over smb, xfs, bcachefs and netfs. That said, driver fixes obviously still dominate the diffstat - “more than perhaps usual” still doesn’t make the filesystem changes that big. I suspect they stand out more mainly because the rest is fairly small.

Outside of drivers (all the usual suspects) and filesystems, we have various architecture fixes (although honestly, that’s mostly arm64 dts files), some core networking, and some selftest updates related to that.

Nothing particularly odd stands out, please do keep testing,”

Linux 6.11 的稳定版按照计划会在 9 月中旬发布。

https://www.kernel.org/ updated by 2024/9/5

关键词: Linux

Linux 已经非常接近完全支持实时 “PREEMPT_RT”

We’re very close to the finish line for the mainline Linux kernel being able to enable real-time “PREEMPT_RT” kernel support.

我们离主线 Linux 内核能够启用实时 “PREEMPT_RT” 特性的目标已经非常接近。经过多年（接近 20 年）的努力，PREEMPT_RT 补丁主线化的工作终于快要结束了。剩下的最后一个障碍是围绕 non-blocking 控制台（或者叫 atomic 控制台）特性的支持，这项工作正在逐渐提交到 linux-next 中，以便可能合并到 Linux 6.12 中。

本周五，来自 Linutronix 的 Sebastian Andrzej Siewior 在 Linux 内核邮件列表中发布了一个新的补丁系列。该补丁的名字叫做 “Allow to enable PREEMPT_RT”，他在补丁系列中写道：

The printk bits required for PREEMPT_RT are sitting in linux-next. This was the last known roadblock for PREEMPT_RT. The RT queue has additionally the “atomic console” for the 8250 UART which is not yet in linux-next. This means “legacy console” behaviour as in no printing from atomic context in emergency cases. The 8250 UART driver is the only one providing “atomic console” support as of today.

With the printk bits merged, PREEMPT_RT could be enabled on X86, ARM64 and Risc-V. These three architectures merged required changes over the years leaving me in a position where I have no essential changes in the queue that would affect them. ARM and POWERPC have a few essential patches left and I lost track of MIPS.

看上去最后的大障碍也已经被克服，虽然目前只有 8250 UART 驱动支持 “atomic 控制台” 特性。使能该特性后，我们目前可以在 X86、ARM64 和 RISC-V 三个架构上尝试 PREEMPT_RT，ARM 和 POWERPC 还差一些工作，而 MIPS 则优先级更低些。

我们将看看 PREEMPT_RT 是否在 Linux 6.12 中合入主线，或者是 6.13 ？6.13 看起来也不错，因为这个内核版本将是 2025 年的第一个稳定系列版本。而 Linux 6.12 计划成为今年的 LTS 内核版本。

借用邮件列表中 Will Deacon 的话：

“Let it rip!”

新闻出处，“Linux Very Close To Enabling Real-Time “PREEMPT_RT” Support”: https://www.phoronix.com/news/Linux-PREEMPT_RT-Close-Patches。

关键词: Linux, PREEMPT_RT

Linux 6.12 将支持在内核崩溃期时显示 QR 码

Submitted today via DRM-Misc-Next to DRM-Next for staging ahead of the Linux 6.12 merge window in mid-September is optional support for displaying a QR code within the DRM Panic handler infrastructure when a Linux kernel panic occurs.

上周末 DRM-Next 中合入了 DRM-Misc-Next 分支上的修改，这些改动将在 9 月中旬 Linux 6.12 合并窗口开启后合入主线。这个改动提供了一项可选的功能，可以在 Linux 内核崩溃发生时基于 DRM Panic 处理程序显示 QR 码。

当 panic 发生时显示 QR 码错误的功能使得调试更加方便。否则，内核崩溃消息在输出时往往会从屏幕的显示中被截断，而 QR 码则能够提供更多大量的信息，而这些信息可能很难从简单的基于文本的输出中获取。

这已经不是像几年前讨论的那样第一次考虑在内核发生错误时提供 QR 码了，其他操作系统也已经提供了类似的功能。

这个 QR 码支持是用 Rust 编程语言编写的，因此必须启用 Rust 内核构建才能获得支持。该支持由 DRM_PANIC_SCREEN_QR_CODE Kconfig 构建选项控制。此外，选项还支持为 QR 包含 URL 用以上报错误以及指定 QR 的格式版本。

新闻出处，“Linux 6.12 To Optionally Display A QR Code During Kernel Panics”: https://www.phoronix.com/news/Linux-6.12-DRM-Panic-QR-Code。

关键词: Linux, DRM, QR Code, Panic

Rust Linux 内核维护者之一宣布退出

One of the several Rust for Linux kernel maintainers has decided to step away from the project. The move is being driven at least in part due to having to deal with increased “nontechnical nonsense” raised around Rust programming language use within the Linux kernel.

Wedson Almeida Filho 是一名来自 Microsoft 的工程师，在过去几年中，他对 Linux 内核代码的 Rust 做出了巨大贡献。Wedson 致力于许多 Rust Linux 内核功能，甚至还用 Rust 开发了一个实验性质的 EXT2 文件系统驱动程序。但他已经受够了当前的状态，决定退出 Rust for Linux 项目的工作。

Wedson 不久前在 Linux 内核邮件列表中宣布退出 Rust for Linux 项目的维护工作。他认为经历了将近 4 年的开发工作后，发现自己花费了太多的时间在回应一些 “nontechnical nonsense”，这些无聊的事情耗尽了他的精力和热情，所以他选择了退出。

很遗憾看到 Wedson 退出了 Rust for Linux 的工作，但至少有其他几位维护者继续监督在 Linux 内核中使用 Rust 编程语言的工作。

新闻出处，“One Of The Rust Linux Kernel Maintainers Steps Down - Cites “Nontechnical Nonsense””: https://www.phoronix.com/news/Rust-Linux-Maintainer-Step-Down。

关键词: Linux, Rust, Maintainer

新补丁为 Rust for Linux 支持 MIPS

When it comes to the Rust programming language support within the Linux kernel one of the limitations is that the CPU architecture support isn’t as widespread. Currently Rust for Linux supports x86_64, AArch64 (ARM64) little-endian, LoongArch, and RISC-V. While those cover the main targets, POWER is notably missing and many other niche CPU architectures supported by the Linux kernel especially for aging platforms. Patches posted today to the Linux kernel mailing list would extend the Rust support to MIPS.

当谈到使用 Rust 语言开发 Linux 内核时，限制之一是对 CPU 架构的支持没有那么广泛。目前 Rust for Linux 支持 x86_64、little-endian 的 AArch64（ARM64）、LoongArch 和 RISC-V。虽然这些涵盖了主要的 ISA，但还是有一些主要的 ISA 没有被支持，譬如 POWER，以及 Linux 内核支持的许多其他小众的 CPU 架构，尤其是对于那些老旧的平台，也一样没有被支持。但本周二我们看到 Linux 内核邮件列表中接收到一个补丁，这个补丁把 Rust 的支持扩展到了 MIPS 上。

Rust for Linux 的部分困难在于依赖于上游基于 LLVM 的 Rust 编译器所支持的架构，同时在 Linux 内核代码侧同样需要一些更改以启用和验证新的 CPU 移植是否可以正常工作。

Jiaxun Yang 提交了这个针对 MIPS 的 Rust 支持补丁，他在邮件中的评论原文如下:

“This series added MIPS arch support to rust for linux, hopefully MIPS is not too late to the party :-)

Sample rust module tested on R4000(el), mips32, mips32r2el, mips64, mips64r2el, mips64r6el.”

有兴趣的人可以通过 Linux 内核邮件列表找到 Linux 内核中为 Rust 启用 MIPS 的补丁。到目前为止，从最初的反馈来看，在代码最终被上游 Linux 内核接受之前，一些新的 MIPS target triples 需要进行一些更改。

新闻出处，“New Patches Bring Rust Linux Kernel Support To MIPS”: https://www.phoronix.com/news/Rust-Linux-Kernel-MIPS-Patches。

关键词: Linux, Rust, MIPS

Android Open-Source Project 发布 Android 15

Google announced today that the Android 15 source code has been released to the Android Open-Source Project (AOSP).

Google 于本周二（9 月 3 日）宣布，Android 15 源代码已发布到 Android Open-Source Project（AOSP）。

Google Pixel 设备还需要几周时间才能够正式上线 Android 15，但在此之前，Android 15 的源代码已经公开可以下载。

Android 15 AOSP 改进了开发者体验、包括排版和国际化、相机和媒体、以及改进了界面和用户体验，同时提高了安全性和隐私性以及许多其他改进。

有关 Android 15 AOSP 版本的更多详细信息，请访问 “Android 开发者博客”(https://android-developers.googleblog.com/2024/09/android-15-is-released-to-aosp.html)。

新闻出处，“Android 15 Released To The Android Open-Source Project”: https://www.phoronix.com/news/Android-15-AOSP-Release。

关键词: AOSP, Android

Debian 12.7 发布，包含许多安全更新

Debian 12.7 is out today as the latest stable release update for the Debian Bookworm series.

上周末，Debian 12.7 作为 Debian Bookworm 系列的最新稳定版本更新发布。

像往常一样，在 Debian 12.7 版本中可以找到数十个错误和安全修复程序。以安全修复的名义更新了 AMD CPU 微码，Calibre 的远程代码执行漏洞，dcm2nix 中的潜在代码执行问题，然后是其他小修复的混合，从处理可能的缓冲区溢出问题到其他问题。

如果希望下载以及查看 Debian 12.7 软件包更改的完整列表可以访问 Debian.org 上的发布公告 https://www.debian.org/News/2024/20240831。

新闻出处，“Debian 12.7 Released With Many Security Updates”: https://www.phoronix.com/news/Debian-12.7-Released。

关键词: Debian

Debian 开发人员正在制定删除更多未维护软件包的计划

While there are more than 74k packages available within Debian’s package management system for x86_64 systems, not all of the packages are well maintained and a portion of them haven’t seen any maintenance/updates in ages. Debian developers have recently begun discussing how to begin removing more of those long unmaintained packages from the archive.

虽然 Debian 的包管理系统中针对 x86_64 系统有超过 7 万 4 千个包可用，但并非所有包都得到良好维护，其中一些包已经很久没有进行任何维护和更新。Debian 开发人员最近开始讨论如何从档案库中删除更多长期不维护的软件包。

最近，Debian 开发者 Helmut Grohne 发起了关于 Debian 开发讨论，讨论从 unstable 档案库中删除更多软件包。他主张更积极地从档案库中删除未维护的软件包，因为这涉及 QA 相关的成本问题，当 Debian 发生重大根本性更改时也会涉及额外的工作并引入大量的复杂性，以及保留旧软件包的其他重要成本。

目前还没有做出确切的决定，但 Debian 项目负责人 Andreas Tille 在 9 月份 DPL 帖子的最新 Bits 中总结了当前的讨论。原文如下：

“I would love for this discussion to lead to more aggressive removals that we can agree upon, whether they are automated, semi-automated, or managed by a person processing an automatically generated list (supported by an objective procedure). To use an analogy: I’ve found that every image collection improves with aggressive pruning. Similarly, I’m convinced that Debian will improve if we remove packages that no longer serve our users well.”

让我们拭目以待，看看 Debian 会采取哪些措施来删除庞大的 Debian 档案库中的那些不维护的软件包。这一定会对 Debain 有很大的改进。

新闻出处，“Debian Developers Figuring Out Plan For Removing More Unmaintained Packages”: https://www.phoronix.com/news/Debian-Debates-Unmaintained-SW。

关键词: Debian

Debian 打算放弃对 bcachefs-tools 的维护

Even before the Bcachefs file-system driver was accepted into the mainline kernel, Debian for the past five years has offered a “bcachefs-tools” package to provide the user-space programs to this copy-on-write file-system. It was simple at first when it was simple C code but since the Bcachefs tools transitioned to Rust, it’s become an unmaintainable mess for stable-minded distribution vendors. As such the bcachefs-tools package has now been orphaned by Debian.

甚至在 Bcachefs 文件系统驱动程序被主线内核接受之前，Debian 在过去五年中就提供了一个 “bcachefs-tools” 软件包，为这个写时复制文件系统提供用户空间程序。起初它是简单的 C 代码，起初很简单，但自从 Bcachefs 工具采用 Rust 改写以来，对于追求稳定的发行版供应商来说，它已经变得很难维护。因此，Debian bcachefs-tools 软件包现在已被 Debian 采用 orphan 方式处理。

Jonathan Carter 在过去五年中一直在 Debian 中维护 bcachefs-tools 包，改用现代 Rust 的代码重写后，他在打包问题上遇到了重重困难，特别是一些依赖问题的解决上，这导致他不得不放弃对该软件的维护。

最初的打算是将 bcachefs-tools 从 Debian 中完全删除，但根据其他 Debian 开发人员的反馈，该软件包将独立出来，从 Debian unstable 中删除，但以 Debian experimental 的方式存在，因此它不会迁移到 testing 状态。旧版本的 bcachefs-tools 也将从 Debian stable 和 Debian oldstable 中删除，因为它们不太可能与当前的上游 Bcachefs Linux 内核代码一起工作。

新闻出处，“Debian Orphans Bcachefs-Tools: “Impossible To Maintain In Debian Stable””: https://www.phoronix.com/news/Debian-Orphans-Bcachefs-Tools。

关键词: Debian, Bcachefs-Tools

联系我们

欢迎扫描二维码加微信联系我们：