前日對鴻蒙微內核進行了抽取，抽取後做了“簡單”瞭解，總感覺有些話要說。
第一個就是內核中包含中文註釋(arch/arm/arm-m/include/los_exc.h)，其實這對於我不懂英文的更好， 但是鴻蒙微內核是“全球”開源的，這就會產生影響。 記得以前抽取Linux kernel時，就有極個別註釋是亂碼， 這會影響我的心情。不知一個非中文閱讀者打開後的心情。
第二就是函數命名規則，每個函數頭必加LOS_或os， 從命名規範講，完全沒有問題，或者說非常規範。 但還是“全球”開源問題，假如我在內核上面開發， 每次調用函數時，必須多敲2個或4個字符，而且還要大寫， 我會不爽的。同時這會給我侷限性很強，開放性不足的感覺。 這也存在於變量、類型和文件命名上。
當然，以上兩點也好理解，因爲華爲最初並非按開源去做這個系統的。 這應該是一個非常棒的企業內部項目，但作爲開源項目，可能需要商榷！
建議華爲的開發幫助手冊也提供英文版本，而不只是中文的。
關於鴻蒙社區培養，我想說說我的建議
社區的壯大，主要看應用是否豐富，爲解決豐富應用問題， 我的想法是針對已有應用，在不需要修改源碼的情況下， 通過編譯或源碼轉換等手段，使現有的應用可以在鴻蒙系統上運行。 這就像生產企業，針對不同的銷售商，採用不同的包裝一樣， 這樣企業的成本變化不大，經銷商也會有面子，實現共贏。
具體做法爲：
1.編譯方法：提供針對類庫，比如windows，接口具有針對性，內部實現爲鴻蒙內核。 這個類似於Wine，但應與Wine存在本質區別，即
a.從使用者角度看，不應存在像Wine的那道牆。
b.從開發者角度看，這是與針對系統一樣的編譯環境。
c.從系統看，沒有虛擬層，這是爲了保證效率。
去年我就想啓動這樣一個開源項目，考慮精力投入太大，還是放棄了！項目應該是一個萬向接口，實現應由不同系統自己耦合，例如windows到redhat，同樣也可以redhat到windows。目前問題主要存在於系統耦合不佳，致使跨平臺開發和遷移繁瑣，如能實現，將極大減輕開發負擔，同時對社區培養有利。
2.源碼轉換法：針對其他系統的源碼，通過工具轉換， 生成可在鴻蒙下編譯的源碼。這個方法可行性不佳，原因是最終的工作量可能大於方法一。
以上方案存在以下幾個問題：
1.成本投入非常巨大，且絕大多數都是由鴻蒙承擔， 沒有辦法，誰讓鴻蒙是後來者呢，與開拓者的投入比較， 心裏就會安生了。
2.法律問題，我不知道會涉及多少法律問題，但肯定存在。
武松山於2020.4.14
原文：www.bricktou.cn