tinyclub/tinylab.org

泰晓资讯 06月 / 第三期 / 2019 —— 资讯收集

lzufalcon opened this issue · 8 comments

Welcome to the LWN.net Weekly Edition for June 6, 2019
This edition contains the following feature content:

This week's edition also includes these inner pages:
Brief items: Brief news items from throughout the community.

image
红色我来做

Fun with LEDs and CircuitPython: a PyCon talk on the joys of hardware-level programming in Python.

来自 2019 PyCon 大会的报道,女程序员 Nina Zakharenko 为大家演示了如何使用 Python 编程操作一些硬件外设来制作一些有趣的小玩意。譬如她在大会上展示的带有可编程 LED 的耳环。

dd

Seeking consensus on dh: the Debian project debates mandating the use of a package-building helper.

Debian 对 Debian 的开发人员在发布包的打包和维护方式上几乎没有什么强制的要求。这给予了开发人员最大的自由度,但同样也给项目带来了一些负面影响。新的 Debian 项目负责人Sam Hartman 在 5 月中旬就针对 Debian 软件包的打包方式的要求主持了一次讨论。可喜的是这次讨论没有像以往那样进入无休止的扯皮而是一定程度上达成某种粗略的共识。让我们拭目以待,获取会取得什么积极的成果。

A ring buffer for epoll: a proposed scalability improvement for epoll that inevitably adds another ring buffer to the kernel API.

应用程序在使用 epoll 机制时首先调用 epoll_create1() (这个系统调用取代了过时的 epoll_create())来创建一个文件描述符,然后再调用 epoll_ctl() 将每个感兴趣的文件描述符添加到 epoll 的监听集合中。最后,调用 epoll_wait() 以阻塞方式等待读写就绪事件在某个文件描述符上出现。这种调用机制比 select()或者 poll() 要麻烦一些,但在多路监听处理上会带来效率上的很大提升。

但现有的 epoll 机制在效率上仍有提升的空间,因为我们发现在以上操作中应用程序为了获取就绪的设备文件描述符,仍然需要多次调用系统调用。在一台繁忙的机器上,如果可以不用切换到内核模式就可以获取就绪的设备文件那该多好呢。Roman Penyaev 为我们带来了一个新的补丁,他的做法是在应用程序和内核之间创建了一个 ring buffer 来传递设备就绪 events,这样我们就可以更加高效地对多路设备进行数据传输了。

Yet another try for fs-verity: a reworked file-protection scheme that appears to have addressed the biggest concerns raised by its predecessors.

Android 平台使用 dm-verity 机制来验证和保护其系统镜像的完整性。但考虑到镜像中的某些关键组件需要增量更新。Google 的工程师们提出了 fs-verity 机制用于文件系统验证单个文件的真实性。 原先的 fs-verity 实现补丁没有被社区接受,所以 Eric Biggers 在五月份又提交了一个新的补丁,这次修改有望被主线所接受。

How many kernel test frameworks?: is the kernel getting too many separate test frameworks?

kselftest 作为 Linux 内核的单元测试框架被提出已经有一段年头了,最近 Brendan Higgins 又提出了另一套类似的框架 - KUnit。但随之而来的问题是,很明显内核并不需要两套类似的单元测试工具。那么 KUnit 相对于 kselftest 究竟是一种重复还是有益的补充,这需要 Higgins 通过实际的功能和解释来证明。

SIGnals from KubeCon: a pair of KubeCon sessions describing the work of two Kubernetes special interest groups.

Kubernetes 项目内部由多个 Special Interest Group (简称 SIG) 构成。每个 SIG 负责一个独立的领域。欧洲 2019 年 KubeCon + CloudNativeCon 大会的主要议题就是给大家介绍每个 SIG 的职责以及未来的计划。来自 Sean Kerner 的报道为大家详细介绍了 Kubernetes 项目中所有 SIG 中的两个非常关键的组,一个是 SIG Release 组,负责制订本项目的具体发布计划,另一个是 SIG Architecture 组,负责思考,设计和改进整个 Kubernetes 的架构。