操作系統專家解讀 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 版本上完成基礎設施的分散式化、國際化。這是從整個社區角度來講，歐拉最關心的兩件事。熊偉稱，運行基礎只要好了，產出一定不會差，但是如果運行基礎不好，還是原先按照堆人力，手動的太多，這個路是走不下去的，因為社區已經大到不可能走下去。

最後，熊偉還談到了關於基礎工作的觀點，「我們做的事不但困難、花費又大、成效又很緩慢。水面下的工作可能並不那麼顯眼，但實際上它真正是我們這個產業最基礎的。」

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive