華為鴻蒙微核心之我見

前日對鴻蒙微核心(huawei liteos kernel是輕量級的實時作業系統)進行了抽取，抽取後做了「簡單」了解，總感覺有些話要說。

第乙個就是核心中包含中文注釋(arch/arm/arm-m/include/los_exc.h)，其實這對於我不懂英文的更好，但是鴻蒙微核心是「全球」開源的，這就會產生影響。記得以前抽取linux kernel時，就有極個別注釋是亂碼，這會影響我的心情。不知乙個非中文閱讀者開啟後的心情。

第二就是函式命名規則，每個函式頭必加los_或os，從命名規範講，完全沒有問題，或者說非常規範。但還是「全球」開源問題，假如我在核心上面開發，每次呼叫函式時，必須多敲2個或4個字元，而且還要大寫，我會不爽的。同時這會給我侷限性很強，開放性不足的感覺。這也存在於變數、型別和檔案命名上。

當然，以上兩點也好理解，因為華為最初並非按開源去做的這個系統。這應該是乙個非常棒的企業內部專案，但作為開源專案，可能需要商榷！

建議華為的開發幫助手冊也提供英文版本，而不只是中文的。

另外，針對英國電信讀華為**困難，原因可能與中文注釋有關。為此華為啟動**重構專案，如果華為**為c或c++（工業大部分是c），程式邏輯抽取器能為華為節約至少三分之二的成本，同時避免源**直接暴露給使用者，實現**安全。期望華為能夠看到這個建議，同時請看到這條資訊的，能夠轉告華為。

關於鴻蒙社群培養，我想說說我的建議

社群的壯大，主要看應用是否豐富，為解決豐富應用問題，我的想法是針對已有應用，在不需要修改原始碼的情況下，通過編譯或原始碼轉換等手段，使現有的應用可以在鴻蒙系統上執行。這就像生產企業，針對不同的銷售商，採用不同的包裝一樣，這樣企業的成本變化不大，經銷商也會有面子，實現共贏。

具體做法為：

1.編譯方法：提供針對類庫，比如windows，介面具有針對性，內部實現為鴻蒙核心。這個類似於wine，但應與wine存在本質區別，即

a.從使用者角度看，不應存在像wine的那道牆。

b.從開發者角度看，這是與針對系統一樣的編譯環境。

c.從系統看，沒有虛擬層，這是為了保證效率。

去年我就想啟動這樣乙個開源專案，考慮精力投入太大，還是放棄了！專案應該是乙個萬向介面，實現應由不同系統自己耦合，例如windows到redhat，同樣也可以redhat到windows。目前問題主要存在於系統耦合不佳，致使跨平台開發和遷移繁瑣，如能實現，將極大減輕開發負擔，同時對社群培養有利。

2.原始碼轉換法：針對其他系統的原始碼，通過工具轉換，生成可在鴻蒙下編譯的原始碼。這個方法可行性不佳，原因是最終的工作量可能大於方法一。

以上方案存在以下幾個問題：

1.成本投入非常巨大，且絕大多數都是由鴻蒙承擔，沒有辦法，誰讓鴻蒙是後來者呢，與開拓者的投入比較，心裡就會安生了。

2.法律問題，我不知道會涉及多少法律問題，但肯定存在。

武松山於2020.4.14

原文：www.bricktou.cn

註解核心贏工具火熱進行中