Zircon架構簡單分析1

有朋友讓我評價一下Zircon的可用性，所以我花了幾天時間大概看了一下這個系統的構架相關資訊。對它的判斷我私下和他說，但看到的基礎事實我記錄在這裡，供其他也有興趣的同行一起探討。

先執行一下看看系統成熟度。按文件的建議（ https:// fuchsia.googlesource.com /zircon/+/HEAD/docs/getting_started.md ），git clone，安裝依賴，build arm64版本（現在只支援x64和arm64兩個平臺），用qemu執行，系統可以輕鬆模擬起來：

這不是個標準的Unix目錄結構，但形式類似。大部分目錄都還是空的，主要的命令在/boot下，這是一個內建的只讀檔案系統，在編譯核心的時候用lz4壓縮直接放到載入映象中，啟動完成後成為一個只讀檔案系統。很多命令還不穩定，一言不合就coredump：

從程式碼上看，核心主要是C++寫的，系統呼叫（參考build-arm64/gen/global/include/zircon/zx-syscall-numbers.h）主要包括這些型別：

clock，sleep，handle，object，channel，socket，thread，process，task，event，futex，port，time，vmo，vmar，prng，fifo，trace，interrupt，pci，pager。

大部分從名字上可以猜出提供什麼功能。我解釋其中幾個關鍵的：

object是物件，類似微軟DCOM中的IUNKNOWN，本質是一個C++的類，核心中的各種管理物件，都是object，使用者態通過handle來訪問它，這提供最基礎的名稱服務。

channel和socket是IPC，一個提供報文式通訊，一個提供流式通訊。

vmo和vmar提供記憶體服務。從vma的定義可以看出這裡的思路：vmo代表一組實體記憶體，可以被vmap等系統呼叫對映到程序空間中被一個或者多個程序使用。而vmar提供程序空間的管理服務。由此可以初步猜測，系統會認為大資料流是通過類似Android的Binder+SurfaceFlinger那樣的IPC加共享記憶體來完成了。

系統呼叫中包含pci和interrupt的介面，基本上可以猜測這是通過使用者態的程序map bar空間，然後等待中斷的形態來完成的。

（提示一句：由於程式碼比較新，現在找程式碼特別容易，知道系統呼叫的名字，找sys_XXXX，基本上就找到入口了）

系統呼叫使用了vdso技術，直接從核心中提供出來，不需要libc來提供了。

從系統呼叫就可以看出，傳統的POSIX程式和Linux核心驅動都不要指望可以無縫遷移過來（這是和QNX很大的不同，QNX上幾乎所有的Unix程式都可以直接遷移的）

它的使用者態程式大概是這個樣子的（看system/uapp目錄可以找到很多）：

zx_status_t ZirconDevice::CallDevice(const zx_channel_call_args_t& args, uint64_t timeout_msec) {
uint32_t resp_size;
uint32_t resp_handles;
zx_time_t deadline;

if (timeout_msec == ZX_TIME_INFINITE) {
deadline = ZX_TIME_INFINITE;
} else if (timeout_msec >= std::numeric_limits<zx_time_t>::max() / ZX_MSEC(1)) {
return ZX_ERR_INVALID_ARGS;
} else {
deadline = zx_deadline_after(ZX_MSEC(timeout_msec));
}

return zx_channel_call(dev_channel_, 0, deadline, &args, &resp_size, &resp_handles);
}

裝置無關的就是標準的C/C++介面，裝置相關的主要是通過檔案系統提供名稱服務找到對方的程序，然後通過IPC服務通訊獲得資料。

到此為止，可以看到Zircon的心的很大的，是打算徹底拋棄Unix世界重頭來的，這也大大增加了它失敗的可能性。

todo：名稱服務的具體實現