不久前,欧拉社区发布了今年的创新版本openEuler22.09。作为欧拉社区贡献给OpenAtom开源基金会后的第一个创新版本,该版本增加了2012万行代码,其中仅Linux内核就增加了4.8万行代码,总数量代码已经达到6.7亿OK!openEuler采用长期支持(LTS)版本和创新版本间隔的发布方式。每两年发布一个LTS版本,在此期间每六个月发布一个创新版本,用于引入实验性技术特性。本次发布的openEuler22.09创新版本,具有多项创新功能。不过Euler社区的官方公告并没有详细介绍这些特性。因此特意请来了华为服务器OS首席架构师、openEuler社区技术委员会成员熊伟,对本次发布的一些最新发布进行讲解,最酷的技术功能。从内核开始,本次openEuler22.09发布公告中提到了几个技术特性,如可编程内核、分布式软总线、嵌入式硬实时。这些新名字给人一种似曾相识的感觉,但却有一种不了解其中奥秘的感觉。作为欧拉技术委员会的专家,熊伟对我的好奇给出了他的回答:什么是可编程内核?“可编程内核”这个词最让我感到困惑——内核不就是代码吗?肯定是编程产生的,那么这个“可编程”是什么意思呢?对此,熊伟首先解释了“可编程内核”的背景,“目前硬件的迭代变化非常快,但相对来说,软件的变化有点滞后。比如芯片的一般生命周期才三年,你要花一年上传到上游,半年后进入内核社区,从社区到用户还有很长的时间,本质原因还是内核比较固定一个开发完成后,编译成一个内核模块之后,就相对固定了。因此,openEuler创新性地借鉴了eBPF的思想,将机制与框架分离,将框架构建到内核中,而实现的功能和策略只需要写好后注入到内核中即可。在实现上,有主要是两个方面:将这种类似eBPF的机制扩展到内核的很多方面,比如扩展到内存、可调度性,让它们都可变;解耦内核中driver与内核主体的绑定。Linux内核中的代码就是驱动,熊伟说,“我们有一个想法,是不是也可以提取内核驱动。现在驱动跟linux内核绑定太紧了,内核驱动也能改吗?”换句话说,就是让驱动和Linux内核版本的演进关系最小化。这样内核版本可以继续演进,但是驱动可以在几个大版本中复用,不像现在的内核。稍微对于“可编程内核”的发展规划,熊伟表示,“从现在开始,我们希望能推出一个比较完整的框架,由明年下半年。“对此,我不禁想到,我们知道内核的所有部分都是模块化的,不仅可以在编译内核时选择和配置不同的模块,而且在运行时也可以根据需要动态加载。那么,“可编程内核”与内核的模块化有什么关系和区别呢?熊伟解释说,内核的模块并不是“完全可变的”,这些内核模块(KO)插入到内核后是固定的,并且在运行过程中不能改变。并且“可编程内核”可以灵活动态地调整。》进一步说,动态加载的不仅仅是模块,还有策略,模块加载后,可以动态提供新的策略,比如可以根据运行的业务使用不同的内核调度器,以适配不同的需求,比如大数据和数据库对内核使用的调度器有不同的要求,对于这样的内核底层机制层面的创新,不仅仅是一些内核驱动或者某个子系统,我非常期待看到它成为分布式软总线是什么?在最近的版本中,openEuler提到了一个“分布式软总线”,这个名词可能有人在鸿蒙操作系统中看到过,这是否标志着进一步融合欧拉与鸿蒙的结合?熊伟表示,openEuler的“分布式软总线”来源于鸿蒙操作系统,“软总线”是万物互联的基础ything,自动发现,自动识别,自动认证,自动连接。翻译后,所有基于openEuler的操作系统和所有基于鸿蒙的操作系统都可以实现相同的特性。openEuler上关于“分布式软总线”的翻译在这个版本就已经开始了,在这个版本已经基本完成了。“分布式软总线”基础设施的工作,相当于提供了一个“基地”,可以在此基础上涌现出哪些有趣的应用和场景,期待合作伙伴和用户去探索。什么是嵌入式硬实时?这次在openEuler22.09也看到了“嵌入式硬实时”的提法。RTLinux的这部分是否加入了openEuler?熊伟首先对“硬实时”这个词进行了澄清:硬实时能力是一个统称,对于如何实时才能称为“硬”并没有明确的定义。实时一般分为三个层次:第一层次是标准的Linux内核,目前的芯片处理能力比较快,只要达到一定的响应速度,其实一般的Linux都能满足大部分实时要求。第二层,在内核中打上了RTLinux补丁,比标准的Linux内核具有更强的实时性。但是第三层,实时性要求会特别严格。例如,对于汽车的刹车系统,Linux目前无法满足相关要求,同时在合规性方面也面临着挑战,所以总体上还是采用专用的实时操作系统。这样的场景。在这方面,Euler社区容纳了很多不同的内核,不仅有Linux内核,还有Zephyr内核,华为贡献的一个小型实时内核uniproton等等。此外,欧拉还在与国产实时操作系统RT-Thread、易慧进行合作。面对复杂的场景,目前社区正在研究的一种解决方案是混合部署方案。比如一个芯片或者一个SOC有8个核,两个核可以分开做实时工作,运行RT-Thread、易慧等实时核,而其他6个核可以运行openEuler的Linux版本,两者之间建立了一个通信机制,两者可以进行交互。实时部分做实时工作,非实时部分充分利用Linux庞大的生态系统,两者通过标准化的语义连接起来,从而兼顾各种场景的需求.熊伟表示,这部分社区还在开发中,年底到明年年初应该可以看到样片。架构支持根据Euler社区公开的信息,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上编译Euler操作系统的数千个软件包,这本身就是一个很大的挑战。但是通过编译只是第一步。第二步首先要会跑,第三步跑好。对于第二步和第三步,对于整个Linux产业线,熊伟觉得RISC-V还有很长的路要走。熊伟表示,“去年上半年我们与国内多家RISC-V厂商进行了交流,并组织了相关的研讨会等活动,目前的情况是大家齐心协力完成技术准备工作,欢迎来到RISC-V.相关厂商基于openEuler开放相关产品。应用场景支持什么是虚拟化混合部署,有什么意义?前面我们在嵌入式硬实时部分提到了一个虚拟化混合部署的场景,熊伟对此进一步展开:我们可以讨论未来的趋势。以汽车为例,汽车分为实时部分和非实时部分。汽车的设计最初是分开的。非实时部分和实时部分各有自己的芯片和自己的线路,但是成本比较高。,结合起来比较复杂。这种趋势可能会在未来出现。这些功能都集中在一块板子上,甚至是一块SOC上,而SOC会分成不同的分区,有实时控制分区,也有非实时控制分区。实时分区用于车辆控制,非实时分区负责车载娱乐系统。这种需求会在很多场景中产生,它的好处是它的成本会降低,交互互联或信息共享会更容易、更方便。openEuler有几个内核,会通过构建系统混合部署,根据不同的场景使用不同的内核。因此,基于混合部署,可能会产生很多有趣的想象。熊伟表示,今年年底可以推出混合部署的样机,明年有望相对成熟。支持云计算/服务器场景针对云计算和服务器场景,openEuler除了支持Intel最新的硬件外,在云原生和混合部署方面也做了很多工作,比如离线/在线混合部署,增强资源利用率。熊伟表示,云和云原生的方向是openEuler的重点。另外,熊伟还提到了一个让我感兴趣的东西,那就是一个新的初始化系统。我们知道,Linux原有的init系统,比如sysVinit,已经在很大程度上被systemd所取代。systemd虽然也带来了许多新的进步,但也因其不透明、复杂、统一而受到广泛批评,违背了UNIX的传统思维。因此Euler社区也在开发新的初始化系统SysMaster,这是一个使用Rust开发的轻量级初始化系统,目前计划首先应用于嵌入式和容器。熊伟表示,原型系统将于今年年底发布,预计未来会支持更多场景。当然,在openEuler社区中,可以根据客户需求选择SysMaster和systemd,在特定场景下可以提供更好的性能和更轻的资源占用。熊伟也表达了Euler操作系统的设计理念,“伴随着这样的背景,openEuler做的很多工作都是尽可能地简化操作系统的组件,而不是让它们变得越来越复杂。”太多的东西也对操作系统造成负面影响。或许有人对科技圈重复造轮子感到不以为然,熊伟表示,“我们强烈建议大家重复造轮子,只有重复造轮子,造出更好的轮子,才能不断推动技术进步。”..例如,OpenSSL存在很多问题。如果有人用Rust或其他语言重写SSL实现,我们非常乐意支持它并将其集成到我们的操作系统中。”Euler对开发者的支持自公布以来据数据显示,Euler社区的开发者和贡献者增长迅速,1265名开发者参与了openEuler22.09的版本贡献,与上一版本相比,参与该版本的开发者数量贡献增加了63%,是openEuler发布版本中开发者数量最多的一次。对此,我和熊伟讨论了Euler社区对开发者做了什么支持,让这么多开发者和贡献者能够贡献出来。熊伟魏对这个话题表示了极大的兴趣,他认为,如果你看Debian、Fedora等操作系统社区,在openEuler之前,甚至openEuler的早期,中国其实还没有一个完整的操作系统社区。阶段,Euler社区是结合了包括华为在内的各个厂商的力量形成的,但坦白讲ng,初期拉肩膀的人比较多,相当于一堆人力。熊伟说,但是从今年开始,Euler真正开始为社区建立一些完善的机制,同时我们也在重建基础设施。比如建立一个统一的账号,之前开发Euler操作系统需要在Gitee上注册一个账号,如果是GitHub上的开发者是没有办法参与的。所以欧拉首先要有一个统一的账号,让这个基础设施分布式,不会绑定到某个托管平台上。通过分布式平台,使用统一的工具从不同的平台拉取到一个构建仓库中进行构建。这样整个基础设施发生了翻天覆地的变化,抽取了公共能力,可以适配不同的平台,你个人的开发行为可以和平台的绑定隔离开来。这样有很大的好处,不仅可以聚集几家厂商的力量,还可以让更多的个体开发者参与进来。这样使得整个社区的运作更加分布式,也便于走向国际化。熊伟表示,基础设施改造完成后,一些自动化工具,包括一些看板、可视化、可量化的评价体系等都得到了完善,为后续社区的国际化和社区的进一步扩展打下了坚实的基础。社区规模。听了这话,我特别受鼓舞。我一直在关注Euler社区是如何发展的。我认为这是下一步发展的重要推动力。说到这里,熊伟也表示,“大家在社区里抱怨很多事情,其实我们都可以听到,技术委员会也可以听到。但是很多事情比较复杂,消耗的工作量很大。”需要有条不紊,我们在一点一点的完善。整个社区的进化,我们肯定有一个明确的计划,一定会实现的,但是大家可能要有点耐心,因为这不可能一蹴而就。”在下个版本的蓝图之后,熊伟也谈到了下个版本的蓝图。社区也在讨论如何更好的让上下游企业让社区的开发节奏适应产品迭代的速度。从目前的规划来看,Euler社区期待在下一个LTS版本中真正做到全场景、全覆盖,真正能够从嵌入式、边缘计算到服务器、云计算打通。目前的全场景还比较简陋,组件只是功能性的。从建筑和基础设施的角度来看,它们仍然是相对独立的组成部分。熊伟说,“至少在我看来,最重要的是把整个事情变成一个大系统,而不是一个单独的系统。”此外,Euler还期望在下一个LTS版本中完成基础分布式和国际化的设施。从整个社区的角度来看,这是欧拉最关心的两件事。熊伟表示,只要运营基础好,产出就不会差,但如果运营基础不好,还是靠人力,手工活太多。这条路走不下去,因为社区太大,走不下去。最后,熊伟还谈到了自己对基础工作的看法,“我们做的事情不仅难度大,而且成本高,做起来慢。在表面下工作可能并不那么明显,但实际上它对我们的行业来说是真正的基础。“
