操作系统专家解读 openEuler 22.09 最新技术特性

openEuler 采用长期支持（LTS）版本和创新版本间隔的发布方式，每两年发布一个 LTS 版本，期间每半年发布一个创新版本，用于推出实验性的技术特性。本次发布的 openEuler 22.09 创新版就带有不少的创新特性。

前不久，欧拉社区发布了今年的创新版本 openEuler 22.09。作为欧拉社区贡献给开放原子开源基金会后的首个创新版本，此版本中新增了 2012 万行代码，其中仅在 Linux 内核上就新增了 4.8 万行代码，全量代码已达 6.7 亿行！

openEuler 采用长期支持（LTS）版本和创新版本间隔的发布方式，每两年发布一个 LTS
版本，期间每半年发布一个创新版本，用于推出实验性的技术特性。本次发布的 openEuler 22.09
创新版就带有不少的创新特性。但是在欧拉社区官方发布的公告中，并没有特别详细地介绍这些特性，因此，我特别邀约了华为服务器 OS
首席架构师、openEuler 社区技术委员会委员熊伟来为我们解读了本次发布中的一些最新、最酷的技术特性。

从内核说起

在本次的 openEuler 22.09 发布公告中提及了若干技术特性，比如可编程内核、分布式软总线、嵌入式硬实时，这些新的名称给人一种似曾相识，但又不明其中奥秘的感觉。作为欧拉技术委员会的专家，熊伟针对我的好奇，给出了他的解答：

什么是可编程内核？

“可编程内核”这个名词是我最迷惑的 —— 内核难道不是代码吗？肯定是编程产生的，那这个“可编程”的意思是什么？

对此，熊伟首先解释了“可编程内核”产生的背景，“现在的硬件迭代变化非常快，但是相对而言，软件的变化就有点跟不上。比如说，芯片一般的生命周期就三年，你得花一年时间上传到上游，半年后进入内核社区，而从社区到用户手里还有很长的周期。本质原因在于内核相对是固定的，一次开发完成以后，编译成内核模块后就相对固定了。”因此，openEuler
创新性地借鉴了 eBPF的思想，将机制和框架分离，框架内置到内核，而实现的功能和策略只需要写完以后注入到内核即可。

在实现上，主要是两个方面：

1. 把这种类似 eBPF 的机制扩展到内核的很多方面。比如说，扩展到内存、可调度性，让它们都成为可变化的；
2. 把内核中的驱动程序和内核主体的绑定解耦。

Linux 内核中的大部分代码都是驱动程序。熊伟说，“我们有一种想法，是不是能把内核驱动也能抽离出来。现在驱动程序跟 Linux
内核绑定得太死了，是不是能把内核驱动也变成可变化？”换言之，让驱动程序和 Linux
内核版本的演进尽量减少关系，这样的话，内核版本可以不断演进，但驱动程序可以在几个大版本内不断复用，而不像现在内核稍微一变化，所有的内核驱动都得重新测试验证甚至重新开发。

而关于“可编程内核”的开发计划，熊伟称，“从现在开始尝试，到明年的下半年，我们期望能推出一个相对比较完整的框架。”

对此，我不禁想到，我们知道内核的各个部分都是模块化的，不但可以在编译内核时选择和配置不同的模块，而且可以在运行中根据需要动态加载。那么，“可编程内核”和内核的模块化有什么关系和区别呢？

熊伟解释称，内核的模块还不是“彻底可变化的”，这些内核模块（KO）插入内核后是固定的，在运行过程中是不能变化的。而“可编程内核，是可以灵活动态进行调整的。”更进一步说，动态加载的不仅仅是模块，更多的是策略，模块加载进去以后可以动态地给它提供新的策略。比如说，可以根据运行的业务使用不同的内核调度器，来适应不同的需求，比如大数据和数据库对内核所采用的调度器是有不同的需求的。

对于这样的一种在内核底层机制层面进行的创新，而不仅仅是某些内核驱动程序或某个子系统，我非常期待在后继的几个版本中看到它变得成熟和更多应用。

什么是分布式软总线？

在最近的几个版本中，openEuler 提到了一个“分布式软总线”，这个名词有的人可能在鸿蒙操作系统中见到过，这是否标志着欧拉和鸿蒙的进一步融合？

熊伟称，openEuler
的“分布式软总线”就是来自于鸿蒙操作系统。“软总线”是鸿蒙的万物互联、自动发现、自动识别、自动认证、自动连通的基础。平移过来以后，凡是基于
openEuler 的操作系统和所有基于鸿蒙的操作系统的设备之间就可以实现同样的特性。在 openEuler
的上个版本中已经开始进行“分布式软总线”的平移，而在此版本中已经基本完成。

“分布式软总线”基础设施的工作，相当于提供了一个“底座”，能在这个基础上出现什么有趣的应用和场景，我们期待合作伙伴和用户去探索。

什么是嵌入式硬实时？

我也看到了这次 openEuler 22.09 中提到了“嵌入式硬实时”，这是将 RTLinux 的部分加入到了 openEuler 中了么？

熊伟首先澄清了“硬实时”这个名词：硬实时能力是个通用词，实时到什么程度才能称作“硬”，这个没有什么明确的说法。实时一般分为三个层次：

第一层，就是标准的 Linux 内核，现在芯片处理能力是比较快的，只要达到一定的响应速度，其实一般的 Linux 可以满足大部分实时的要求。

第二层，在内核中打上 RTLinux 补丁，相对于标准的 Linux 内核具有更强的实时性。

但是第三层，对实时性要求就会特别严格。比如汽车的刹车系统，目前Linux
是达不到相关的要求的，同时合规层面等也都面临挑战，所以一般这类场景中还是选用专用的实时操作系统。对此，欧拉社区容纳了多个不同的内核，不仅仅是
Linux 内核，还包括了 Zephyr 内核、一个华为贡献的小型实时内核 uniproton 等。此外，欧拉也在和国内的实时性操作系统
RT-Thread、翼辉等形成合作。

面对纷繁复杂的场景，社区目前正在做的一个方案是混合部署方案。比如说，一个芯片或一个 SOC 中有 8
个核心，可以分出两个核做强实时性的工作，运行 RT-Thread、翼辉等这种实时内核，而另外六个核可以跑 openEuler的Linux
版本，两者之间构建通信机制，两者之间可以进行交互。实时部分做实时的工作，非实时部分充分利用 Linux
庞大的生态，两者再通过标准化的语义联通起来，这样就能兼顾各种场景的需求。熊伟称，这个部分社区还正在开发当中，应该在年底到明年年初大家可以看到样例。

对架构的支持

根据欧拉社区披露的信息，openEuler 全版本支持 x86、ARM、申威、龙芯、RISC-V
五种架构，支持众多的芯片厂商的多种芯片，多个硬件厂商发布的多款整机型号、板卡型号，支持网卡、RAID、FC、GPU&AI、DPU、SSD、安全卡七种类型的板卡，具备良好的兼容性。

对国产的龙芯和申威等架构的支持是应有之义。此外，随着内核对树莓派的支持，包括 openEuler 在内的各个 Linux 发行版也都纷纷提供了对最新的树莓派板卡的支持。

此外， openEuler 对 RISC-V 的支持也引起了业界关注。RISC-V 被誉为硬件里的
Linux，因其开放性而广受开源界的追捧。提及 RISC-V 支持，熊伟说，对于单板级的产品来讲，RISC-V
的成熟度已经比较高，但对于边缘计算以上的，比如说服务器、桌面，差距还是比较大。如果想在 RISC-V
上把欧拉操作系统的数千个软件包都编译过，这个本身就是一个很大挑战。但编译通过还只是第一步，第二步你得先能跑起来，第三步是要跑得好。第二步、第三步对于整个
Linux 产业线来讲，熊伟觉得 RISC-V 还有比较长的路要走。

熊伟说，“我们在去年上半年和国内很多 RISC-V 厂商都有过沟通，还组织过相关的讨论会等活动，现在的情况是大家先合力把技术准备工作做好，欢迎 RISC-V 相关厂商基于 openEuler 来开放相关产品”。

对应用场景的支持

什么是虚拟化混合部署，其意义何在？

前面我们在嵌入式硬实时部分提到一种虚拟化混合部署场景，熊伟就此做了进一步展开：对于未来的趋势可以探讨一下。以汽车为例，汽车上分为实时部分和非实时部分，汽车设计起初是分离式的，非实时部分和实时部分都是各走各的芯片，各走各的线路，但这样成本就比较高，结合起来也比较复杂。未来可能会出现这种趋势，这些功能都集中在一个板卡上，甚至一个
SOC 上，而 SOC
会分成不同的分区，有实时控制的分区，有非实时控制的分区。实时分区进行车辆控制，非实时分区负责车载娱乐系统。在很多场景上都会产生这种需求，其好处就是它的成本会降低，交互和互联或者信息共享更加容易方便。openEuler
有几种内核，会通过构建系统进行混合部署，根据不同的场景采用不同的内核。

所以，基于混合部署可能会催生出很多有趣的想象力，熊伟称，今年年底可以推出混合部署的一个原型，明年有望变得相对比较成熟。

对云计算/服务器场景的支持

对于云计算和服务器场景的支持，除了对英特尔最新硬件的支持之外，openEuler 还在云原生、混合部署方面做了较多工作，比如离线/在线的混合部署，增强了资源利用率。熊伟称，云以及云原生方向是 openEuler 的发力重点。

此外，熊伟还提到了一个令我颇感兴趣的东西，即一个新的初始化系统。我们知道，Linux 最初的初始化系统，比如
sysVinit，已经基本上被 systemd 所取代。虽然 systemd 也带来很多新的进步，但是其也因不透明、庞杂、大一统等有违 UNIX
传统思维的做法而广受诟病。因而，欧拉社区也在开发一个新的初始化系统 SysMaster，它是一个使用 Rust
开发的轻量级初始化系统，目前计划首先应用在嵌入式和容器中。熊伟称，今年年底将会发布原型系统，并预期未来会支持更多的场景。

当然，在 openEuler 社区里，SysMaster 和 systemd
可以按照客户的要求自行选择，在特定场景下可以提供更好的性能、更轻量的资源占用。熊伟还就此表达了欧拉操作系统的设计理念，“沿这个脉络出发，openEuler
做的很多工作都是期望把操作系统的部件尽量简化，而不是越做越复杂。做事太多对操作系统也是一种负面影响。”

可能有人会对技术圈重复造轮子感到不以为然，熊伟说，“我们是非常强烈地建议大家重复造轮子的。重复造轮子，造更好的轮子才能不断推动技术的进步。比如说
OpenSSL 问题也比较多，如果谁用 Rust 或者其它语言重写了SSL 实现，我们也非常乐意支持，会融合到我们的操作系统当中。”

欧拉为开发者提供的支持

从这次公布的数据来看，欧拉社区的开发者、贡献者增长迅速。有 1265 名开发者参与了 openEuler 22.09 的版本贡献，相较于上一个版本，参与版本贡献的开发者数量新增 63%，是 openEuler 已发布的版本中开发者数量最多的一次。

对此，我和熊伟进行了讨论，欧拉社区为开发者做了什么支持，才能有这么多的开发者、贡献者参与贡献。熊伟对这个话题表示了很大的兴趣。他认为，如果对标
Debian、Fedora 等操作系统社区来看，在 openEuler 之前，甚至是 openEuler
早期，其实中国是没有一个完整的操作系统社区的。

在开始阶段，欧拉社区是以包括华为在内的各个厂商的力量结合在一起组成的，但坦白来讲，开始阶段还是人拉肩扛这种方式比较多，相当于堆人力。熊伟说，但是从今年开始，欧拉开始真正地把社区的一些综合性的机制建立起来了，同时我们正在重构基础设施。比如建立统一账号，之前欧拉操作系统的开发需要在
Gitee 上注册账号进行，而如果是GitHub
上的开发者就没办法参与。所以，欧拉首先要有一个统一账号，把这个基础设施变成分布式的，不会强制捆绑到某一个托管平台。通过分布式平台，使用统一的工具从不同的平台上拉取到一个构建仓进行构建。

这样，整个基础设施做了脱胎换骨式的变革，把公共能力抽取出来，可以适配不同的平台，你个人的开发行为和平台的绑定就可以进行隔离了。这样做有非常大的好处，不光是可以集合几个厂商的力量，还可以让更多的个人开发者参与进来。这使得整个社区的运作更加分布化，同时也容易走向国际化。熊伟说，基础设施改造完成后，一些自动化的工具，包括一些看板、可视化、可量化的评估体系都健全了，社区后续走向国际化、社区规模的进一步扩大也就有了坚实的基础了。

这一点我听了以后特别受鼓舞，我一直在看着欧拉社区是怎么发展起来的，我认为这是下一步发展的重要动力。

说到这里，熊伟也说，“大家在社区里抱怨很多事情，其实我们都是听得到的，技术委员会都听得到。但是很多事情是比较复杂的，消耗的工作量很大，这需要有条不紊地在一点一点去改进。整个社区的演变，我们肯定是有清晰规划的，一定会实现，但是大家可能要稍微耐心点，因为它不可能一蹴而就。”

下一个版本的蓝图

之后，熊伟还谈到了之后的版本蓝图。社区也在讨论如何更好的使得上下游企业，把社区的开发节奏和产品迭代速度相适应。

从目前的计划来看，欧拉社区期望能在下一个 LTS
版本中真正实现全场景、全覆盖，真正能够从嵌入式、边缘计算到服务器、云计算全部拉通。目前的全场景还是比较初级的，组件只是能通，从构建、从基础设施角度来讲还都是比较分离的组件。熊伟称，“至少从我的角度来讲，最重要的就是把整个东西都能变成一个大的体系，而不是分离性的系统。”

此外，欧拉还期望在下一个 LTS
版本上完成基础设施的分布式化、国际化。这是从整个社区角度来讲，欧拉最关心的两件事。熊伟称，运行基础只要好了，产出一定不会差，但是如果运行基础不好，还是原先按照堆人力，手动的太多，这个路是走不下去的，因为社区已经大到不可能走下去。

最后，熊伟还谈到了关于基础工作的观点，“我们做的事不但困难、花费又大、成效又很缓慢。水面下的工作可能并不那么显眼，但实际上它真正是我们这个产业最基础的。”