泰晓资讯·7月 / 第一期 / 2020

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

Linux 5.7 开发周期数据盘点

The 5.7 kernel was released on May 31. By all appearances this was a normal development cycle, unaffected by the troubles in the wider world. Still, there are things to be learned by looking at where the code came from this time around. Read on for LWN’s traditional look at who contributed to 5.7, who supported that work, and the paths by which it got into the mainline.

Work on 5.7 arrived in the form of 13,901 non-merge changesets contributed by 1,878 developers; that makes it rather busier than the 5.6 cycle was. It’s notable that 281 of those developers made their first contribution to the kernel for 5.7, the highest number since 5.0; that is a distinct contrast from 5.6, which saw the lowest number of new contributors since 2013. Perhaps being made to stay at home has inspired more people to put together and send in that first kernel patch.

5.7 版本的内核于 5 月 31 日正式发布了。看起来这仍然是一个很正常的开发周期，并没有受到当今世界上那些纷纷扰扰的影响。5.7 版本中有 13,901 个补丁提交，分别来自 1,878 位开发者。这两个指标比 5.6 版本开发周期的要高，说明本次周期更加繁忙。值得注意的是在 5.7 有 281 位作者是首次为 kernel 贡献 patch，这个数值是 5.0 版本以来的最高的一次，尤其是跟 5.6 比起来对比很明显，因为 5.6 的这个数据是 2013 年以来的最低点（记得当时还为此发出了些许感叹）。也许是近期的疫情影响，导致大家被迫待在家中，反而鼓励了人们来整理、发出他们人生中的第一个正式内核补丁？。

在 5.7 开发周期中最活跃的开发者列表如下。顺便提一下，Gustavo A. R. Silva 在按 changeset 数量排序中排名第一，主要是因为他在持续进行的一个改动（把 kernel 中各处 structure 中长度为 0 的数组替换成变长数组）；每次 Greg Kroah-Hartman 在 “line changed” 这一列登顶，一般都是因为他删除了许多代码，这次也不例外 :-)。

![5.7-developers](/wp-content/uploads/2020/07/weeky-news-7-1/5.7-developers.png)

可以辨认出来的，为 5.7 贡献代码的公司数量有 215 家。其中最活跃的列表如下（国内 IT 公司还是要加油，特别地什么时候国内的半导体电子厂家大量进入这个榜单的时候我们就再也不用害怕被人卡脖子的事情了）：

其他更多精彩数据请阅读原文 [“Development statistics for the 5.7 kernel”](https://lwn.net/Articles/821813/)。

关键词: Linux，5.7

在 Deadline 调度器中加入对 CPU capacity 的考量

The Linux deadline scheduler supports realtime systems where applications need to be sure of getting their work done within a specific period of time. It allocates CPU time to deadline tasks in such a way as to ensure that each task’s specific timing constraints are met. However, the current implementation does not work well on asymmetric CPU configurations like Arm’s big.LITTLE. Dietmar Eggemann recently posted a patch set to address this problem by adding the notion of CPU capacity to the deadline scheduler.

为支持实时系统的需求。Linux 内核提供了两个 realtime scheduling class，他们分别是：POSIX realtime scheduler 和 Deadline schedular。POSIX realtime scheduler 基于任务优先级调度任务，优先级越高，其任务将越优先被调度运行。Deadline schedular 不使用优先级，而是考量任务的另外三个参数：运行时长（run time）、周期（period）和截止时间（deadline）。感兴趣的同学可以读一下另一篇介绍 Dealine Schedular 的文章（https://lwn.net/Articles/743740/ ）。

但是针对非对称系统，譬如现在移动终端中最常见的 基于 ARM 的 big.LITTLE 架构或 DynamIQ 方式，Deadline schedular 所面对的工作会更加复杂。这类系统包括不同类型的 CPU，性能有高有低。同样的任务在性能较高（”big”）的 CPU 上运行时，会比在性能较低（”little”）的 CPU 上运行时耗时更短。当前内核中的 Deadline schedular 并没有考虑到这种差异，它可能会在性能较低的 CPU 上分配过多 CPU 时间。Deadline 所管理的任务可能最终会落在一个 LITTLE CPU 上，导致无法在截止时间前完成工作。

可见，问题的本质原因是目前的 Deadline scheduler 没有考虑 CPU 的 capacity 信息（即一个 cpu core 的处理速度，或者严格点讲即指一个 cpu core 在给定时间内可以执行的指令数量）。更多关于它的计算方法的细节可以参考 “这里”。CPU capacity 因素已经在负载均衡和其他情况下被考虑，比如当处理器发热过高时内核会调节 CPU 的频率，以及最近针对 realtime scheduler 的改进都考虑了 CPU capacity 的影响。好在最近 Eggemann 提交了一个补丁，就是希望针对 deadline scheduler 也加入对 CPU capacity 的考量，从而解决非对称系统下的调度失效问题。更多详细内容请阅读原文 “Capacity awareness for the deadline scheduler”。

关键词: Linux，Deadline scheduler，CPU capacity

OpenZFS 0.8.4 发布，内核兼容性扩展到 Linux 5.6

OpenZFS / ZFS On Linux 0.8.4 is out as the latest update to this leading open-source ZFS filesystem base for Linux and FreeBSD and coming together as well for macOS.

With OpenZFS 0.8.4, Linux kernel compatibility is from Linux 2.6.32 now up through Linux 5.6 as well as early work on Linux 5.7 support, compared to the prior release tapping out at 5.4.

OpenZFS 0.8.4 also has a number of bug fixes, better AES-GCM performance, init script updates, enhancements to the systemd mount generator, and other miscellaneous changes.

Linux 上领先的开源 ZFS 文件系统 OpenZFS/ZFS 发布了最新版本 0.8.4（参考其 github 网站的发布：https://github.com/openzfs/zfs/releases/tag/zfs-0.8.4），该文件系统库适用于 Linux 和 FreeBSD，以及 macOS。

在 OpenZFS 0.8.4 中，对 Linux 内核的兼容性从 2.6.32 一直到 5.6，以及早期对 Linux 5.7 的支持，而以前只支持到 5.4。

OpenZFS 0.8.4 还修复了许多错误，改善了 AES-GCM 性能和初始化脚本，对 systemd 挂载生成器进行了增强，以及其他杂项更改。

更多讯息请参考原文 “OpenZFS 0.8.4 Released With Support Through Linux 5.6, Bug Fixes”。

关键词: OpenZFS

GCC 11 将默认前端语言改为 C++ 17

Following the proposal at the end of last year over GCC 11 aiming to default to C++17 for its C++ front-end, that change is now in place for GNU Compiler Collection 11.

When not specifying any alternative C++ standard, the default revision has been C++14. But with GCC’s C++17 support being mature now for over a year, with the GCC 11 release due out next year it will assume C++17 by default.

As of Friday, the change is in place for using C++17 as the default dialect. That commit conveniently outlines some of the language benefits in moving to C++17 by default. Those on GCC9/GCC10 can use -std=gnu++17 for seeing the same affect as well.

GCC has already been ironing out its C++2A/C++20 support but that would be too soon for the default change-over to happen yet.

继去年年底针对 GCC 11 提出计划将其 C++ 前端默认改为 C++ 17 之后，GNU Compiler Collection 11 的这一更改现已到位。当前如果未指定替代的 C++ 标准，默认版本为 C++ 14。 而 GCC 11 版本将于明年发布，它将默认使用 C++ 17。

更多讯息请参考原文 “GCC 11 Now Defaults To C++17 Dialect By Default”

关键词: GCC 11，C++ 17

KDE 社区迁移至 Gitlab

After our final decision to adopt GitLab in November 2019, KDE started the work of tackling the many challenges that come with moving a whole development platform for a large open source community. KDE has now officially completed Phase One of the adoption and contributors have begun to use GitLab on a daily basis.

自从 2019 年 11 月，KDE 社区宣布计划迁移至 Gitlab 后，几经努力，截至目前，它已正式完成迁移计划的第一阶段，并加入了 GitLab 的开源计划。

KDE e.V 的主席 Aleix Pol 表示，降低门槛、简化贡献者的工作是选择 Gitlab 的主要原因。他还认为，“使项目贡献者轻松参与的测试和交付方式无疑将成为我们生态系统的转折点。”

更多讯息请参考 ["KDE 官宣"](https://dot.kde.org/2020/06/30/kdes-gitlab-now-live)。

**关键词**: KDE，Gitlab

联系我们

资讯内容部分来自 “LWN.net“。如果您对某些 LWN 文章感兴趣（譬如希望获得全文翻译的）请扫描二维码加微信联系我们：