LWN：Zephyr四年啦！

关注了就能看到更多这么棒的文章哦～

Four years of Zephyr

June 29, 2020
This article was contributed by Martí Bolívar and Carles Cufí
原文来自：https://lwn.net/Articles/824029/

Zephyr project ，这是一个开源项目，希望提供一个开源的实时操作系统（RTOS），可以在作为介于Linux这种功能齐全的操作系统和完全没有操作系统的环境之间的这种需求。Zephyr已经公布4年了。本文中，随着2020年6月它发布了v2.3.0 release，我们来介绍一下项目的进展以及社区状况。此外也对项目的未来做了一些预测。

两位作者都是Nordic Semiconductor公司内部的Zyphyr开发者。Cufí 是v2.3.0版本的发布经理。

A Zephyr primer

Zyphyr虽然可以用来支撑大型的系统，这个RTOS的主要目标还是不具备MMU的微处理器环境，一般CPU频率不超过100MHz，带有不超过512KB的片上NOR flash存储和32到256KB的内置RAM。Zyphyr也像Linux kernel一样，可以用Kconfig方式来进行配置，devicetree来描述硬件。

Zephyr有一点跟其他的RTOS很不一样，它不仅是一个kernel而已。这个RTOS配备了你所需要的所有功能。它的目标就是能提供你在开发、发布、维护过程中的所有软件，包括编译器、烧写和调试工具。zephyr的代码库里面包括kernel, 协议栈，驱动程序，文件系统等等。Zyphyr还包括许多第三方的项目，都通过一个名为west的工具集中拉了下来。这些第三方项目包括加解密库，硬件抽象层（HAL），协议栈，和MCUboot bootloader。

Zephyr是一个library operating system。它的编译系统里面把应用程序、kernel、以及其他代码都合并成一个单一静态链接生成的可执行程序，所有代码都在同一个地址空间内（大多数微处理器反正也没有MMU）。每个编译生成的image都是针对一个特定开发板的，通常是从闪存里面直接开始执行。因此所有配置工作基本都是在编译阶段完成的。代码中用到的buffer缓存也都是静态预先分配好的。整个devicetree在编译时都可以访问，因此会挑一部分设备和驱动程序编译进来。这样就可以让image size最小化，能在闪存中塞入尽量多的内容，节省空间非常小的RAM。

有些功能会针对Zephyr不能self-host而量身定做的。这样Zephyr开发者在编译应用程序的时候就会把全部内容都编译进来。Zephyr开发的新手可以很快上手，因为它有基于CMake和Python的跨平台编译和配置系统，可以直接在Linux, macOS, Windows上面进行编译，这都归功于Kconfig和devicetree的处理都从原来的Unix工具转到了Python 3。这个非常重要，因为Windows是微处理器固件开发中最常用的开发环境。

More details

Zephyr kernel支持多种体系架构，也支持多种调度算法。可以支持cooperative或者preemptive therad，也有多种措施可以减少中断延迟以及确保关键线程的执行。还有一个可选模式，名为user mode，可以利用许多微处理器里的MPU（Memory Protection Unit）来对各个线程做隔离，确保线程之前无法互相破坏memory，也能保护kernel。

Zephyr支持6种主要体系架构（x86, Arm, ARC, NIOS II, Xtensa, RISC-V），也可以在模拟器环境中运行。部分体系架构中32和64位的处理器都可以支持。Arm架构中的重点放在了主流的32位Cortex-M处理器上了，不过对于Cortex-R和Cortex-A（包括64位）也有试验性的支持。除了这些真实硬件外，Zephyr也可以在QEMU上运行，或者作为一个ELF可执行程序来执行。它可以支持simulated radio，这样在测试和debug RF（radio ferquency）问题时可以节省时间和开销。总共已经支持了超过200种开发板（包括模拟平台）。

Zephyr包括了日志系统和shell功能。并且都可以配置底层的传输通道。比如传统的串口（log和shell都支持），或者走网络（支持log）。log功能也可以是异步的，也就是可以用一个独立的线程来发送log信息，每次调用log API的时候都会把compact message发到一个队列中去就行了，这样非常快，哪怕在中断上下文也可以使用log API了。

硬件相关的API都是参照一个轻量级的device driver model来开发的，跟kernel紧密集成了起来。现在已经支持了许多种外设和传感器。还支持多种存储解决方案，既有NOR flash优化过的key-value键值对存储方式，也有文件系统支持。

Zephyr还缺省提供了多种通讯协议栈。它的网络协议栈具有BSP类似的socket API接口，支持多种协议。Zephyr还有一个完全开源的Bluetooth Low Energy (BLE)协议栈，可以支持多种硬件设备。此外还有一个802.15.4协议栈，支持Thread协议。CAN（Controller Area Network）总线和USB device通讯方式也是直接支持的。Zephyr还额外支持通过多种传输层来进行firmware升级。

But why, though?

关于Zephyr最常见的一个问题就是为什么需要这么一个项目，毕竟现在已经有了那么多种RTOS可供选择。

微处理器已经变得越来越强大了，也有了更多的memory、core（CPU核心）、安全功能，也需要支持更多种复杂的协议和通讯功能。Firmware的复杂度在这几年大大增加。因此，普通芯片厂商来提供的自研framework，同上都是直接基于裸代码或者最小化的一个kernel之上，现在就变得越来越难于开发和维护了。Zephyr本身期望能成为一个非常容易扩展的方案，大家一切开诚布公地合作开发，把所有功能都围绕着一个公共的API提供出来。

Zephyr已经有多个社区用户了。Zephyr的member公司肯定会希望用它，还有一些芯片厂商也支持Zephyr。比如说，NXP和Nordic Semiconductor作为member厂商就提供了不少硬件。STMicro也贡献了一些SoC和传感器的代码并且一直在支持相关用户。还有许多其他体系架构和开发板也得到了支持。并且还有一个活跃的开源社区，下一节里我们来讲讲。

Who's behind all of this?

Zephyr是Linux基金会的一个项目，有许多付费会员来支持和管理。不过它的开发工作完全是开源的。任何人想使用或者贡献给Zephyr都可以，不需要成为会员。

项目的会员公司包括许多芯片厂商，设备制造商，开发组织，等等。经费主要用来支持持续集成、网站维护、市场费用等相关的支持工作。会员可以获得投票席位来决定项目的Techincal Steering Committee (TSC)，这个管理层完全由会员公司来组成。

所以不少人把这个项目看成一个pay-to-play的工业组织，不过这并不完全公平。至少从代码和其他一些技术贡献上来说，Zephyr是一个完全开源的项目。Patch和review是任何人都可以进行的。core Zephyr repository是按Apache 2.0协议发布的，贡献者可以对它们贡献的部分保留copyright。在v2.3.0版本中，大概有1/4的commit的提交者不是来自会员公司。

项目中的会议，包括TSC的会议基本都是任何人都可以参加的，可惜是用了一个商业软件来进行视频会议。会议记录也都会发给mailing list。

Zephyr开发主要在GitHub上进行。patch都是通过pull request来提交的。那些不属于security的bug都是直接由GitHub issue来管理的。各个子系统的maintainer对于他们自己的领域都有责任。这些maintainer也都是需要TSC批准的，不过任何人都可以成为maintainer，并不局限于会员公司。现在就有一些maintainer不是来自会员中的。

Zeyphyr项目的user和developer这两个mailing list都很活跃，也都可以搜索查到历史记录。交谈主要是通过Slack的。可以看到项目的帮助页面里面有这些信息。

Wrapping up

Zephyr除了在不断扩充和改进它的现有功能之外，也会继续添加新的功能。下个版本中（预计9月份发布）就打算包括如下功能：Bluetooth advertising extensions，对device model的重构，改善支持MMU的系统（例如demand paging），初步支持一个新的TCP stack，改进编译器支持从而可以使用商用编译器或者LLVM。

我们可以看到，Zephyr的优势主要是它填补了裸代码和全功能操作系统之间的空白。尽管它才出现不久，其实已经完成了许多工作。这个项目有着远大的野心，希望能为firmware开发来提供许多即开即用的功能。希望我们已经解决了大家的疑惑，今后能看到更多的LWN读者来参与到Zephyr中来。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注LWN深度文章以及开源社区的各种新近言论～