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

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

Linux Kernel 5.6 正式发布

From	Linus Torvalds <>
Date	Sun, 29 Mar 2020 15:51:35 -0700
Subject	Linux 5.6
share
So I'll admit to vacillating between doing this 5.6 release and doing
another -rc.

This has a bit more changes than I'd like, but they are mostly from
davem's networking fixes pulls, and David feels comfy with them. And I
looked over the diff, and none of it looks scary. It's just slightly
more than I'd have preferred at this stage - not doesn't really seem
worth delaying a release over.

So about half the diff from the final week is network driver fixlets,
and some minor core networking fixes. Another 20% is tooling - mostly
bpf and netfilter selftests (but also some perf work).

The rest is "misc" - mostly random drivers (gpio, rdma, input) and DTS
files. With a smattering of fixes elsewhere (a couple of afs fixes,
some vm fixes, etc).

The shortlog is appended, nothing really looks all that exciting, and
most of the discussions I've seen are already about things for the
next merge window.

Which obviously opens now as of the release, and I'll start doing
pulls tomorrow. I already have a couple of pull requests in pending in
my inbox - thank you.

And while I haven't really seen any real sign of kernel development
being impacted by all the coronavirus activity - I suspect a lot of us
work from home even normally, and my daughter laughed at me and called
me a "social distancing champ" the other day - it may be worth just
mentioning: I think we're all reading the news and slightly
distracted.  I'm currently going by the assumption that we'll have a
fairly normal 5.7 release, and there doesn't seem to be any signs
saying otherwise, but hey, people may have better-than-usual reasons
for missing the merge window. Let me know if you know of some
subsystem that ends up being affected.

So we'll play it by ear and see what happens. It's not like the merge
window is more important than your health, or the health of people
around you.

                  Linus

这周初，Linus Torvalds 宣布 Linux Kernel 5.6 正式发布，此举也意味着 Linux 5.7 合并窗口的开放。经过一系列改进之后，Linux Kernel 5.6 版本中包含的一些亮点内容有：对 WireGuard VPN 的支持、对 USB4 的初始支持、对亚马逊 Echo 智能扬声器的支持，以及许多其他显著改进。

“与上周相比，大约一半的差异是网络驱动程序的补丁包和一些次要的核心网络修复程序。另外 20% 有关工具开发。其余的是一些杂项，主要包括一些驱动程序（gpio、rdma、input）和 DTS 文件。以及其他地方的少量修补程序。”

针对近期肆虐的新冠病毒可能产生的影响，Linus 则表示，因为大多数工程师基本都在家办公，所以新冠状病毒爆发不太可能对下一版内核更新的开发产生重大影响。不过，他也表示，由于社会隔离和大流行，预计经济将会放缓。

更多详细的 5.6 版本修改请参考 这里。

关键词: Linux，5.6

Linux Lab 发布 v0.4 rc1，完善基础体验

Linux Lab 于三月初发布了 v0.3 正式版，在刚刚过去的三月末又再次发布了 v0.4 的第一个候选版本：v0.4-rc1，一同发布的还有 Cloud Lab 的 v0.2-rc2。

本次主要是多处细微的基础体验改善，合计 40 笔变更，变更不算多，但是对 v0.3 而言，都是很重要的增强：

• 默认的 Linux 内核源码镜像站从清华源切换到 codeaurora
  • 新的镜像更为快捷稳定，感谢 Ping Wu 提交
  • 感谢 codeaurora 社区，也感谢一直提供内核镜像的清华源，期待有更多镜像站增加内核、工具链等方面的镜像服务
• 其他 Linux 变更
  • 提交一笔遗漏的文件
  • makefile 性能优化
  • 完善 bsp 下载功能，避免切换开发板失败
  • 添加本地开发板配置和编辑接口
  • 恢复 build 目标的直接执行
  • 修复一笔 sync 导致的偶现卡死问题
• Cloud Lab 关键变更
  • 把系统默认时区改为 Asia/Shanghai
  • 允许随时保存和恢复实验环境中的修改：tools/docker/commit
• 文档更新
  • 完善中英文文档“目录”和相应的自动生成脚本 tools/toc.sh
  • 补充环境保存、调试、登陆和开发板配置相关的说明

更多有关 Linux Lab v0.4-rc1 的发布信息请参考 这里。

关键词: Linux Lab，0.4-rc1

国产基础软件的重大里程碑：MiniGUI 5.0 正式发布！

飞漫软件于 2020 年 3 月 30 日宣布，正式发布 MiniGUI 5.0.0 版本，并同时更新 HybridOS 图形栈。 MiniGUI 5.0 带来的三个全新特性如下：

• 自 MiniGUI 5.0.0 起，MiniGUI 的多进程模式开始支持合成图式（compositing schema）。合成图式是现代桌面操作系统和智能手机操作系统的图形及窗口系统使用的技术，其基本原理很简单：系统中所有进程创建的每一个窗口都使用独立的缓冲区来各自渲染其内容，而系统中有一个扮演合成器（compositor）角色的进程，负责将这些内容根据窗口的 Z 序以及叠加效果（如半透明、模糊等）合成在一起并最终显示在屏幕上。以前，MiniGUI 被主要用于不安装第三方应用的电子产品中，如功能手机、视频监控、工业控制、医疗仪器等。而有了合成图式，MiniGUI 还可以应用在桌面电脑、智能手机等可能支持第三方应用的设备中。
• MiniGUI 5.0 版本还增强了 MiniGUI 的窗口管理器以支持某些特殊的主窗口类型。引入了主窗口 Z 序级别的概念，这项增强功能使我们可以创建一些特殊的应用，该应用可以作为锁屏、通知栏、程序坞或者启动器使用。
• 在 MiniGUI 5.0 之前，以独立进程模式或者多进程模式下运行的 MiniGUI 不支持线程间的消息传递能力。在 MiniGUI 5.0 中取消了这一限制，并引入了虚拟窗口的概念。此增强功能为基于 MiniGUI 的应用开发提供了非常有用的基础设施，以开发设计良好的多线程应用程序。

除了以上三个主要的增强之外，MiniGUI 5.0 还调整了一些底层架构，重构了一些底层模块。有兴趣的读者可以阅读完整的发布说明文档：https://gitlab.fmsoft.cn/VincentWei/minigui/blob/rel-5-0/RELEASE-NOTES.md

最后，附上 MiniGUI 5.0 的入口仓库：https://gitlab.fmsoft.cn/VincentWei/build-minigui-5.0 或者 https://github.com/VincentWei/build-minigui-5.0

关键词: MiniGUI，5.0

即将来到的 HTTP 3.0

The Hypertext Transfer Protocol (HTTP) is a core component of the world-wide web. Over its evolution it has added features, including encryption, but time has revealed its limitations and those of the whole protocol stack. At FOSDEM 2020, Daniel Stenberg delivered a talk about a new version of the protocol called HTTP/3. It is under development and includes some big changes under the hood. There is no more TCP, for example; a new transport protocol called QUIC is expected to improve performance and allow new features.

HTTP（Hypertext Transfer Protocol，超文本传输协议）是互联网的核心基础之一。从 1991 年出现发展至今，协议本身也不断演进，但其缺点来也越来越明显了。Daniel Stenberg 在 FOSDEM 2020 会议上的演讲介绍了一组新的协议，名为 HTTP/3。该协议尚在开发中，引入了许多大的变动，比如不再用 TCP，而是使用一个全新的传输层协议 QUIC ，改善了性能并提供了许多新的功能。

HTTP/1.0 基于 TCP 传输明文，为了支持安全性，引入了 HTTPS（Hypertext Transfer Protocol Secure）。HTTPS 在现有的传输协议栈之上增加了一层新的的安全层 TLS（Transport Layer Security），于是现有协议栈就变成了（按从底到上的顺序）：IP，TCP，TLS，HTTP。目前据统计互联网上有 80% 的 HTTP 请求都采用了加密传输。

在 HTTP/1.0 中默认使用 “短连接”。也就是说，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个 Web 页面中包含有其他的 Web 资源（如 JavaScript 文件、图像文件、CSS 文件等），每遇到这样一个 Web资源，浏览器就会使用 “短连接” 重新建立一个 HTTP 会话。为了提高页面的加载速度，浏览器会同时并行创建多个连接。这样一来大大增加了服务器这边需要同时处理的连接数量，再加上 TCP 固有的低效连接建立阶段操作（slow-start 或者叫 “慢启动” 问题）和可能的 “head-of-line blocking” 问题，这都导致了 1.0 版本运行效率低下。1997 年时改进版 HTTP/1.1 里面增加了一个重大改动，即默认使用长连接（Persistent Connection），当打开一个网页后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭（Keep-Alive），客户端再次访问这个服务器时，会继续使用这一条已经建立的连接，提升了 TCP 效率，这样就大大改进了 “慢启动” 问题。

2015 年提出的 HTTP/2.0 则规定每个主机（host）都使用一个单独的连接承载多条 HTTP stream，极大提高了传输速度，但对 “head-of-line blocking” 问题却有潜在加重倾向。另外考虑到现实互联网中存在难以计数的老旧设备，特别是那些旧的路由器设备，由于这些旧设备中的软件很难得到持续的维护和升级（典型的案例是这些旧的系统会直接丢弃新协议中的新字段），造成了一些 2.0 中的新特性根本无法在互联网上得到有效支持。

考虑到以上种种原因，IETF 在 2016 年建立了名为 QUIC 的工作组，至于为何起这个名字，是由于最初的工作是基于 Google 的 一个叫做 QUIC 的实验版本，但目前 IETF 开发的版本跟当初 Google 的版本已经非常不同了，它包括了一个新的传输层协议 QUIC 以及应用层协议 HTTP/3.0。

QUIC 解决了 “head-of-line blocking” 问题，支持类似 TCP 上 “fast open” 这样的行为以加速数据传输。该协议内置加密，已完全不支持明文传输了。QUIC 跟 TCP 的一大区别在于如何管理一个连接内的多个传输 stream。QUIC 可以在一个连接内发送多个 stream，stream 是双向的并且完全独立，可以由 server 端发起也可以由 client 端发起。一旦发生丢包，QUIC 可以知道丢包具体发生在哪个 stream 上，因此只有这个 stream 才需要等待重传。每一个 stream 独立地确保自己传输上的可靠性和有序性。

基于 QUIC 的应用层协议，我们称之为 HTTP/3.0，实际上是由多个协议组成。协议的定义从 HTTP 开始，其他协议如 DNS 等会逐个进行改进。其他的应用层协议估计会在 QUIC 发布之后开始进行。最终协议发布的日期还没有确定（这的确是一件大工程），为了确保稳妥。IETF 希望能在 2020 年 7 月发布。目前的代码都是在 alpha 版本而且同样是为了稳妥，协议栈的实现目前还在用户态并没有合入内核。除此之外，各种工具，浏览器都需要更新，因此相对于2.0，3.0 协议的广泛部署应用肯定需要更多时间，不过长久来说我们对 HTTP/3.0 还是充满了期待。

更多内容欢迎阅读原文 “A QUIC look at HTTP/3”。

关键词: HTTP，3.0

“消极（negative）” 的 DENTRY（目录项）

Back in 2017, Waiman Long posted a patch set placing limits on the number of “negative dentries” stored by the kernel. The better part of three years later, that work continues with, seemingly, no better prospects for getting into the mainline. It would be understandable, though, if many people out there don’t really know what negative dentries are or why kernel developers care about them. That, at least, can be fixed, even if the underlying problem seems to be more difficult.

2017 年时，Waiman Long 曾经提出过一个补丁，希望限制内核中保存的所谓 “negative dentries” 的数量。3 年过去了，Long 看上去还在这个补丁上工作并又提交了一版新的修改，虽然和前几次的遭遇一样，对这个补丁的讨论还没有任何结论就迅速冷却下来（所以看上去这个补丁仍然不能被合入主线），但这个补丁涉及的 “negative dentries” 概念倒是比较有趣，正好借此机会给大家介绍一下。

大家知道，dentry 和 inode 一样，都是 VFS 和实体文件系统（ext2、ext3等）中比较重要的概念。inode 用于保存内核中文件对象的元数据，而 dentry，即 “目录项” 在内核中起到了连接不同的文件对象 inode 的作用，进而起到了维护文件系统目录树的作用。dentry 作为一个纯粹的内存结构，会在应用程序访问文件过程中由文件系统在内存中直接建立。内核提供 dentry 的好处在于将曾经解析过的路径 cache 在内存中，这样在后继访问过程中可以避免重新解析，这可以大大加速文件路径的搜索过程，尤其是针对那些频繁访问的目录（如 /tmp, /dev/null）等，最终可以节省大量的文件系统的读写 I/O 操作。

而所谓的 “negative dentry” 指的是对文件目录树搜索过程中发生了操作失败而遗留在内存中的 “目录项” 记录，譬如输入的命令中访问了一个不存在的文件或者路径。当然对这类操作所缓存的 dentry 并起不到加速访问的效果，除非这个用户不停地尝试这个不存在的路径 :(。但即使不考虑这些异常操作，在我们的日常操作中依然会在内存中产生很多的 “negative dentry”，最典型的莫过于搜索加载动态链接库的过程，系统会在多个可能路径中搜索库文件直到真正找到它，而在此过程中由于会尝试多个不存在的文件路径而产生许多的 “negative dentry”。一个典型的例子，假如我们在系统上编译一个 “allmodconfig” 的内核，就会观察到了 52,799,262 次文件查找失败，想想这会在内存中缓存多少个无效的 dentry 项，那一定是个非常巨大的数字。

这就是 “negative dentry” 的来源，由于它们需要占用内存空间。当生成许许多多的 “negative dentries” 时，甚至可能导致内存太紧张从而把其他一些有用数据也挤出去了。Long 的补丁目标就是希望对这些 “negative dentry” 做些限制。虽然大家都不反对限制一下这些 “negative dentry” 的数量上限。有争议的只不过是这里所选择的实现方式。

更多内容欢迎阅读原文 “Dentry negativity”。

关键词: Linux，dentry

联系我们

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