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

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

Linux 5.8 rc release 汇总

• 5.8-rc5, released on July 12.
  • 5.8-rc4, released on July 5. It’s worth noting that the 5.8-rc5 release will raise the minimum GCC requirement to version 4.9.
• 5.8-rc3, released on June 28.
• 5.8-rc2, released on June 21.
• 5.8-rc1, released on June 14. By the end of the merge window, 14,206 non-merge changesets found their way into the mainline repository, making this one of the busiest development cycles ever. “So in the 5.8 merge window we have modified about 20% of all the files in the kernel source repository. That’s really a fairly big percentage, and while some of it is scripted, on the whole it’s really just the same pattern: 5.8 has simply seen a lot of development. IOW, 5.8 looks big. Really big.”

关键词: Linux，5.8, rc relases

让 BPF program 可以睡眠

When support for classic BPF was added to the kernel many years ago, there was no question of whether BPF programs could block in their execution. Their functionality was limited to examining a packet’s contents and deciding whether the packet should be forwarded or not; there was nothing such a program could do to block. Since then, BPF has changed a lot, but the assumption that BPF programs cannot sleep has been built deeply into the BPF machinery. More recently, classic BPF has been pushed aside by the extended BPF dialect; the wider applicability of extended BPF is now forcing a rethink of some basic assumptions.

多年前，当经典（classic）的 BPF 功能被添加到内核中时，BPF 程序在执行过程中并不需要考虑支持阻塞的问题，因为当时它们的功能非常简单，只限于检查数据包的内容，并决定数据包是否应该被转发。随着内核的进化，BPF 已经发生了很多变化，但在 BPF 程序中不可以睡眠的假设已经成为了 BPF 机制中的一个默认潜规则了。最近，由于 extended BPF 这种 classic BPF 的改进版本表现出更广泛的适用性，人们的注意力逐渐为其所吸引，这也导致现在人们重新思考 classic BPF 中的一些基本假设是否合适（这自然也包括了前面所涉及的睡眠问题）。

最近 Alexei Starovoitov 提交了一组补丁希望对此有所改进。这个补丁集已经进化到第五版，很可能在 5.9 合并窗口期间进入内核 mainline。更多有关该补丁的介绍请阅读原文 “Sleepable BPF programs”。

**关键词**: Linux, BPF, Sleepable

是时候设计一个新的 futex API 了

The Linux futex() system call is a bit of a strange beast. It is widely used to provide low-level synchronization support in user space, but there is no wrapper for it in the GNU C Library. Its implementation was meant to be simple, but kernel developers have despaired at the complex beast that it has become, and few dare to venture into that code. Recently, though, a new effort has begun to rework futexes; it is limited to a new system-call interface for now, but the plans go far beyond that.

内核内要实现同步（譬如互斥等）有许多种选择，但在用户空间要实现类似的操作，可选择的方案一直较少。除了 System V semaphores 之外（可惜的是：由于它如此的难用以致其从未受到广泛的欢迎），可能就是 futex 机制了。

早在 2002 年，Rusty Russell 就提出了一种快速的在用户空间实现互斥的机制（fast user-space mutex mechanism），并很快演进为人们现在所知道的 “futex”。2003 年底发布的 2.6.0 内核中就出现了这个功能，并马上用在了 POSIX 线程的并发控制上。futex 的好处是当不存在对互斥锁的争夺时，对互斥锁的获取和释放不需要涉及系统调用，也就不会涉及内核。不过，一旦发生对 futex 互斥锁的争夺，情况就不一样了，为了将任务将阻塞，需要引入对 futex() 系统调用的调用，但这也是必须的。

随着时间的推移，futex 接口变得越来越复杂，更多信息请参见这篇文章（https://lwn.net/Articles/360699/ ，虽然有些过时了）的概述，以及 man 手册的介绍（https://www.man7.org/linux/man-pages/man7/futex.7.html）。

当前对 futex 的改进工作，首先来源于希望创建一个比 futex() 更有意义的系统调用接口，这个接口的实现本来是很简单的，现在已经变得非常复杂了，很少有开发者愿意去深入研究那些代码。不过最近，André Almeida 开始重构 futexes，虽然目前这个工作仅限于发明一个新的系统调用接口，但计划远不止于此。更多内容请阅读原文 “Rethinking the futex API” 。目前看起来新的 futex 功能的实现过程可能不会那么快。

**关键词**: Linux, futex

内核正考虑是否要移除 bpfilter

The bpfilter subsystem, along with its “user-mode blobs” infrastructure, attracted a lot of attention when it was merged for the 4.18 kernel in 2018. Since then, however, development in this effort has been, to put it charitably, subdued. Now, two years after its merging, bpfilter may be in danger of being removed from the kernel as a failed experiment.

bpfilter 子系统，以及与之搭配的 “user-mode blobs” 机制，在 2018 年合入 Linux 4.18 的时候吸引了很多人的注意。不过在那之后，相关的开发工作却停滞下来，现在已经合入 2 年了，bpfilter 领域没有看到更多值得介绍的开发工作，kernel 里面也没有其他地方利用 user-mode helper。为此社区有人（Eric Biederman）提出，作为一个失败的试验项目，如果是现在这个模样，还不如把它从 kernel 里面移除掉算了。

Alexei Starovoitov 很快就跳出来反对这个建议，Starovoitov 回复说 bpfilter 功能需要更多的时间，直到最近才刚刚克服了某些限制，这主要是得益于 5.8 版本中合入的 “BPF iterator” 功能。但他又 补充说：他并不反对现在把 bpfilter 功能拿掉，可以等到今后在这个领域有了切实进展（至少需要6个月时间）之后再恢复回来。

Linus Torvalds 也表达了自己的观点：他指出这部分代码其实根本就没有用起来，也对最开始提出使用 user-mode helper 的这个主意表示了质疑。

这个讨论中，关于是否要删除代码，目前还没有结论。根据过去的经验来看，如果有开发者积极争取保留的话很少会有代码被移除的情况。不过就算是这样，人们肯定不会同意一直保留这些没有用处的代码。如果后续还是没有真正的进展的话，bpfilter 最终这还是会被移除的。更多详细内容，请阅读原文 “Rethinking bpfilter and user-mode helpers”。

关键词: Linux, bpfilter

RISC-V 国际开源实验室发布全球首个全开源可运行 Linux 的 RISC-V 平台

Risc-V International Open Source Laboratory (RIOS Laboratory) unveiled its Linux-based PicoRio project for construction of cutting-edge computing platform featuring more transparency, low power consumption and customized capability.

The project, headed by David Patterson, a world-renowned expert in the field of computer architecture, marks an actual output stage of RIOS Laboratory based at the Tsinghua-Berkeley Shenzhen Institute.

日前，2017 年图灵奖得主大卫·帕特森教授（David Patterson）领衔的 RISC-V 国际开源实验室（RIOS：RISC-V International Open Source Lab）发布了全球首个可运行 Linux 的全开源 RISC-V 微型电脑系统 PicoRio 项目，用于构建更透明、低功耗、定制能力强的高效能边缘计算平台。

作为对标树莓派（RaspberryPi）的新一代微型电脑主板，PicoRio 的特点是芯片级的全开源设计、低功耗、体积小，可通过 USB 连接鼠标和键盘，具备普通个人电脑的大部分功能，可运行 Linux 操作系统浏览网页，使用 Java、Python 等高级语言进行编程。它也可以直接使用电池供电，连接各式传感器，以应用于物联网等深度嵌入式应用。

PicoRio 最大的特点是从 CPU 设计，到 PCB 电路板设计，再到操作系统核心软件全部开源，核心架构使用最新的开源 RISC-V 指令集技术。其研发设计由 RISC-V 精简指令架构的发明人、图灵奖得主大卫·帕特森教授领导。除高质量工业级的开源 IP 之外，PicoRio 还将提供开源的参考 SoC 设计，以及详尽的集成文档。

更多报道请阅读新闻页 http://www.sz.gov.cn/en_szgov/news/latest/content/post_7915320.html。

关键词: RISC-V，PicoRio

Zephyr 四岁了！

The Zephyr project is an effort to provide an open-source realtime operating system (RTOS) that is designed to bridge the gap between full-featured operating systems like Linux and bare-metal development environments. It’s been over four years since Zephyr was publicly announced and discussed here (apparently to a bit of puzzlement). In this article, we give an update on the project and its community as of its v2.3.0 release in June 2020; we also make some guesses about its near future.

Zephyr project 是 Linux 基金会旗下的一个开源实时操作系统（RTOS）项目，针对的是介于 Linux 这种复杂而全面的操作系统和过于简单的裸机系统之间的那部分客户需求。

基于以上目标，Zyphyr 主要支持的硬件是那些不具备 MMU 的微处理器环境，一般 CPU 频率不超过 100MHz，带有不超过 512KB 的片上 NOR flash 存储和 32 到 256KB 的内置 RAM。Zephyr 有一点跟其他的 RTOS 很不一样，它不仅是一个 kernel 而已。zephyr 的代码库里面包括 kernel，协议栈，驱动程序，文件系统等等。此外还包括许多第三方的项目，可以通过一个名为 west 的工具来集中获取。Zephyr 支持 6 种主要体系架构（x86, Arm, ARC, NIOS II, Xtensa, RISC-V），也可以在诸如 QEMU 这样的模拟器环境中运行。总共已经支持了超过 200 种开发板（包括模拟平台）。

对 Zephyr 这个项目，有许多付费会员来支持和管理。不过它的开发工作完全是开源的。任何人想使用或者贡献给 Zephyr 都可以，不需要成为会员。项目的会员公司包括许多芯片厂商，设备制造商，开发组织，等等。经费主要用来支持持续集成、网站维护、市场费用等相关工作。Zephyr 的开发主要在 GitHub 上进行。Zeyphyr 项目的 user 和 developer 这两个 mailing list 都很活跃，也都可以搜索查到历史记录。交流上主要是通过 Slack。

我们可以看到，Zephyr 的优势主要是它填补了裸机系统和全功能操作系统之间的空白。尽管它才出现不久（截至本文发布 Zephyr 才四岁），但它已经完成了许多工作，2020 年 6 月它刚发布了 v2.3.0 版本。希望今后能看到更多的开发人员参与到 Zephyr 这个项目中来。更多详细的介绍，请阅读原文 “Four years of Zephyr”。

**关键词**: Zephyr

联系我们

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