最近一直在研究開源鴻蒙系統，但碰到一個問題，卡殼了，弄得我茶不思飯不想。在上一篇文章鴻蒙系統研究之四：根檔案系統中，碰到一個難題：
這個問題的原因是 Linux 核心編譯時，沒有開啟 SELINUX。然而開啟 SELINUX 選項後，碰到了更大的麻煩：
Run /init as init process
random: crng init done
init: init first stage started!
init: [libfs_mgr]ReadFstabFromDt(): failed to read fstab from dt
init: [libfs_mgr]ReadDefaultFstab(): failed to find device default fstab
init: Failed to fstab for first stage mount
init: Using Android DT directory /proc/device-tree/firmware/android/
init: [libfs_mgr]ReadDefaultFstab(): failed to find device default fstab
init: First stage mount skipped (missing/incompatible/empty fstab in device tree)
init: Skipped setting INIT_AVB_VERSION (not in recovery mode)
init: Loading SELinux policy
SELinux: policy capability network_peer_controls=1
SELinux: policy capability open_perms=1
SELinux: policy capability extended_socket_class=1
SELinux: policy capability always_check_network=0
SELinux: policy capability cgroup_seclabel=0
SELinux: policy capability nnp_nosuid_transition=1
SELinux: (dev mmcblk0p2, type ext4) has no security xattr handler
audit: type=1403 audit(1625477182.800:2): auid=4294967295 ses=4294967295 lsm=selinux res=1
selinux: SELinux: Loaded policy from /vendor/etc/selinux/precompiled_sepolicy
audit: type=1404 audit(1625477182.800:3): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295 enabled=1 old-enabled=1 lsm=selinux res=1
audit: type=1400 audit(1625477182.810:4): avc: denied { read } for pid=1 comm="init" name="plat_file_contexts" dev="mmcblk0p2" ino=382 scontext=u:r:kernel:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
selinux: No path given to file labeling backend
selinux: selinux_android_file_context: Error getting file context handle (No such file or directory)
audit: type=1400 audit(1625477182.820:5): avc: denied { read } for pid=1 comm="init" name="product" dev="mmcblk0p2" ino=35 scontext=u:r:kernel:s0 tcontext=u:object_r:unlabeled:s0 tclass=lnk_file permissive=0
audit: type=1400 audit(1625477182.820:6): avc: denied { read } for pid=1 comm="init" name="vendor_file_contexts" dev="mmcblk0p2" ino=1259 scontext=u:r:kernel:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
audit: type=1400 audit(1625477182.820:7): avc: denied { read } for pid=1 comm="init" name="etc" dev="mmcblk0p2" ino=27 scontext=u:r:kernel:s0 tcontext=u:object_r:unlabeled:s0 tclass=lnk_file permissive=0
init: execv("/system/bin/init") failed: Permission denied
audit: type=1400 audit(1625477182.840:8): avc: denied { execute } for pid=1 comm="init" name="init" dev="mmcblk0p2" ino=156 scontext=u:r:kernel:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
audit: type=1400 audit(1625477182.860:9): avc: denied { read } for pid=1 comm="init" name="libbacktrace.so" dev="mmcblk0p2" ino=770 scontext=u:r:kernel:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
audit: type=1400 audit(1625477182.880:10): avc: denied { read } for pid=1 comm="init" name="init" dev="mmcblk0p2" ino=156 scontext=u:r:kernel:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
init: #00 pc 00048b13 /system/bin/init
init: #01 pc 00068dcf /system/bin/init
init: #02 pc 0000857d /system/lib/libbase.so
init: #03 pc 0004b1fd /system/bin/init
init: #04 pc 00059213 /system/lib/bootstrap/libc.so
SeLinux 是用來增強 Linux 系統安全的，在聊一聊可信執行環境這篇文章中，我談到過，有時太過于安全，會給使用者帶來不便。就如同有些系統強制要求使用者設定複雜的密碼，但複雜的密碼又不便于記憶。SeLinux 也是如此，很安全，但特别複雜，稍微弄錯一點規則，就造成程式無法執行。在我以往做的産品中，由于 SeLinux 引起的麻煩數不勝數，最後幹脆關閉掉。
帶着這樣的思路，我也是打算把 SeLinux 模式設定為 Permissive （隻列印 log ，但不做權限限制）。從網上找了很多資料，也求助過鴻蒙系統的開發人員，還是未能解決問題。當然這也是我水準不足的原因，我之前做系統開發，但并沒有涉及核心這一塊，隔行如隔山，還需要進一步學習和研究。
這段時間一直沉浸在開源鴻蒙系統中，所謂愛之切，責之深，在此忍不住要吐槽一下開源鴻蒙系統。
首先是文檔問題。大多數開源系統都存在文檔不足的問題，而且很多開發人員信封源碼就是最好的文檔。但開源鴻蒙系統的問題并不在于文檔少，而在于有些混亂，比如：
Ubuntu 編譯環境準備就有三個文檔，内容也各不相同，到底應該讀哪個文檔。就算是有的文檔适合标準系統、有的适合 Lite OS，那也應該寫清楚。這樣弄幾個文檔，還不如沒有文檔。
其次，開源鴻蒙系統中使用了 AOSP 的預編譯庫和程式。開源鴻蒙系統使用 AOSP 的源碼沒問題，但像這樣基礎系統都使用 AOSP，似乎有些說不過去。而且也沒有說明使用哪個版本的 AOSP ，就在源碼系統中放入了二進制檔案，這對于第三方移植非常不友好。我在前面碰到的 init 執行問題，遲遲不好解決，就因為這個超級程式 init 是用 AOSP 預編譯出來的，出了問題，我也沒法通過源碼去查問題。
再次，還是要吐槽一下開源鴻蒙系統的建構系統，混雜了 GN、Make、JSON、Python腳本、Bash腳本等等，這是逼迫程式員擁有十八般武藝，才能把這些整明白。更讓人痛苦的是，有些建構檔案又是通過腳本生成的，這對于追蹤問題又豎了一道障礙。
最後，開源鴻蒙系統并沒有提供一個标準的參考平台，而是以海思的 3516DV3000 作為參考産品。研究 3516 的 kernel patch 和 kernel config 就讓人痛苦，到底哪些是針對 3516 這個特定硬體的 patch，哪些是針對鴻蒙系統的 patch，讓人難以分辨。patch 中還引入了符号連結，連結到開源鴻蒙系統的 driver，沒有像 AOSP 那樣，kernel 和系統可以分開編譯。也許如果和華為公司合作，這些都不是事兒。但對于普通開發者或者小公司，想嘗鮮鴻蒙系統，太困難了。
前幾天看到消息，榮耀系列也開始收到鴻蒙系統的推送，鴻蒙系統接入使用者破 3000 萬，的确是一個了不起的成績。也許華為現在全部的力量都投入到對現有産品的适配上，來不及顧及開源項目。但對于作業系統而言，生态無疑更加重要，而生态有賴于更多玩家的入場，僅僅靠華為一家無法建構整個作業系統生态。希望華為能投入更多的力量在開源項目上，将鴻蒙系統移植到更多的産品上。
接下來我還會繼續開源鴻蒙系統的移植，敬請關注！