微內(nèi)核的差異性及開發(fā)工作

1.本文目的

隨著RT-Thread Smart微內(nèi)核發(fā)布會的臨近，對于開源社區(qū)以及國產(chǎn)RTOS比較關(guān)注的人或許早有耳聞。RT-Thread要發(fā)布微內(nèi)核操作系統(tǒng)了。從去年的華為提出鴻蒙微內(nèi)核到目前為止，都未曾真正見到一個微內(nèi)核系統(tǒng)面向大眾。從真正的開發(fā)者角度來看，或許真正的關(guān)注點不在于多少先進技術(shù)的提出，而實際的關(guān)注點在于是否好用，是否能夠快速高效的開發(fā)出穩(wěn)定的產(chǎn)品，是否用上了之后能夠減少自己的工作量。本文主要從微內(nèi)核開發(fā)的思維角度出發(fā)，談一談RT-Thread Smart以及我個人進行微內(nèi)核開發(fā)工作的所思所想。

2.微內(nèi)核的差異性

內(nèi)核是操作系統(tǒng)中管理資源的核心部分，它充當著計算機程序與硬件之間橋梁。

其實在程序運行時，用戶態(tài)程序想要訪問外設(shè)，必須要通過內(nèi)核進行資源調(diào)度，然后進行統(tǒng)一的管理?，F(xiàn)在許多CPU中，最基本的都會有用戶模式和超級管理員模式兩種。用戶程序首先必須要有可以自己管理的一段內(nèi)存空間，進行業(yè)務(wù)邏輯的設(shè)計，如果要使用到共享資源或者硬件資源時，那就需要通知內(nèi)核，此時內(nèi)核進行調(diào)度和分配，在合適的時機給申請資源的應(yīng)用程序。如果訪問特殊的寄存器，這時候，還需要切換CPU的模式，從而訪問超級管理員才能使用的寄存器。

這種權(quán)限的控制核心都是由內(nèi)核進行，用戶態(tài)程序申請訪問內(nèi)核資源的時候，通常是通過軟件中斷的形式實現(xiàn)，這會導(dǎo)致硬件的中斷處理程序?qū)⒖刂茩?quán)轉(zhuǎn)移到作為操作系統(tǒng)一部分的適當?shù)闹袛嗵幚沓绦蛏希谶M程中將模式位轉(zhuǎn)換為內(nèi)核模式。中斷處理程序檢查生成了哪個中斷，如果合適，檢查附加參數(shù)（通常通過寄存器傳遞），然后調(diào)用適當?shù)膬?nèi)核服務(wù)例程來處理系統(tǒng)調(diào)用請求的服務(wù)。

此時如果用戶程序訪問了非法指令，或者訪問了本不該自己訪問的東西，也會產(chǎn)生軟件中斷，從而將事件交給內(nèi)核處理，內(nèi)核進行保存錯誤日志，并負責清理垃圾。

上述也僅僅介紹了內(nèi)核態(tài)與用戶態(tài)的基本工作流程，微內(nèi)核基本也是沿用了這套思想，但是微內(nèi)核體現(xiàn)的正是這個微的特定。為了體現(xiàn)微這個特點，微內(nèi)核一般只會提供最少的進程和內(nèi)存管理的服務(wù)，客戶端程序與應(yīng)用程序只在用戶地址空間之間進行消息的傳遞，這樣并不會影響內(nèi)核的功能，但是這樣的方式會大大增加消息傳遞的負載，也就是說，大量的消息傳遞也會降低系統(tǒng)的運行性能。但這些犧牲帶來的好處也是顯而易見的，對開發(fā)者來說非常的方便，不用過分關(guān)注內(nèi)核的穩(wěn)定性問題，只需要好好處理上層的業(yè)務(wù)邏輯即可。

3.微內(nèi)核該怎么寫應(yīng)用程序？

微內(nèi)核的應(yīng)用程序部分一般不需要過度的去關(guān)注內(nèi)核部分的代碼，就像我們進行Linux開發(fā)應(yīng)用程序一樣。首先應(yīng)該充分的相信微內(nèi)核內(nèi)核部分的可靠性，如果一出問題就總是懷疑內(nèi)核是不是有BUG那就不太適合進行微內(nèi)核的開發(fā)工作。我們在開發(fā)Linux的時候，遇到問題，總不會把Linux的整個代碼再review一遍，這樣是費力不討好。

所以進行微內(nèi)核的開發(fā)工作，首先需要知道微內(nèi)核提供的編程規(guī)范，以及所提供的API函數(shù)進行程序設(shè)計。其實在C語言中，也是會提供一些標準庫函數(shù)的，比如RT-Thread Smart中提供的musl庫等等。當然還有不同微內(nèi)核系統(tǒng)中所提供的專用的API，比如對RT-Thread比較熟悉的人，在上手RT-Thread Smart時，也能夠找到很多之前用到的函數(shù)API的接口的影子。

而APP的編譯是獨立的，只需要交叉編譯工具鏈，將程序鏈接到指定的入口地址，無論是通過makefile還是scons或者CMake都做不做限制，編譯出來的程序，微內(nèi)核通過加載器加載到內(nèi)存中去執(zhí)行程序。

另外編寫應(yīng)用程序需要注意的是不同線程之間的消息傳遞機制，以及線程與進程之間的關(guān)系。這個是非常值得關(guān)注和思考的問題。

4.微內(nèi)核的效率和實時性怎么樣？

我覺得微內(nèi)核的實時性是弱于RTOS強于LInux的，之所有有這樣的結(jié)論，是因為微內(nèi)核確實會存在大量消息傳遞機制傳遞消息的問題。對于直接進行處理事件的RTOS來說，這樣的方式必然會降低系統(tǒng)響應(yīng)的速度。如果業(yè)務(wù)邏輯簡單倒是看不到很明顯的差異，但是一旦涉及到任務(wù)量大，應(yīng)用程序很多的情況時，內(nèi)核的負載太大了。

例如在用戶態(tài)進行網(wǎng)絡(luò)協(xié)議棧的處理上來說，如果說驅(qū)動在內(nèi)核層，網(wǎng)絡(luò)協(xié)議棧在用戶層，數(shù)據(jù)將直接從內(nèi)核驅(qū)動過來，然后通過消息傳遞機制比如共享內(nèi)存?zhèn)鬟f到用戶態(tài)，用戶態(tài)接收到通知，然后再拷貝數(shù)據(jù)，處理數(shù)據(jù)，然后通過系統(tǒng)調(diào)用，又將處理好的數(shù)據(jù)傳遞到內(nèi)核層。這個過程涉及到太長的鏈路，一定會影響系統(tǒng)的性能。但是如果驅(qū)動在應(yīng)用層，那也需要大量的消息傳遞機制來確保兩個進程間的通信的迅速以及準確?？傮w說起來，對于目前高性能的處理器來說，性能一般不是太大的瓶頸，架構(gòu)的穩(wěn)定與系統(tǒng)復(fù)雜度也是需要好好均衡的，魚與熊掌不可得兼，舍魚而取熊掌者也，至于其中的利弊，個人來做評判與選擇。

5.如何客觀的評價RT-Thread Smart混合微內(nèi)核？

從我的角度去看這個東西，或許是用瑕不掩瑜這個詞語概況比較恰當一點。凡事在開始階段，都是在摸著石頭過河，沒有人會知道這個東西的真正面目是什么，也沒有人徹底的能夠描繪出它的全貌，所以開發(fā)的過程一步一步的進行的是挖坑再填坑的過程，剛開始沒有輪子，然后慢慢有了一個輪子形狀的東西，能轉(zhuǎn)但是很奇怪，因為并不方正。然后慢慢的砍成一個方形的，之后慢慢磨，終于變成圓形的了，這時候就走的很順暢了。我說的上述過程大概就是我做了一點微內(nèi)核的開發(fā)工作的心路歷程吧。

真正的做下來，沒有什么嘗試是毫無意義的。造不如買，買不如租這種思維模式，收益的也只是眼前，從長遠的大趨勢上來看，唯有走在最前面的人，才能看得到最好的風景。這次RT-Thread Smart 混合微內(nèi)核的發(fā)布，具體能夠有哪些東西值得關(guān)注，我后面再慢慢細說。我不敢說這個是一個極其好用的東西，但是我覺得至少走出了第一步，這也是一個突破。更多的功能完善，更加穩(wěn)定的實現(xiàn)細節(jié)可能需要的是更多的努力吧，還有需要更多人的智慧，才能不斷推進技術(shù)走向更高的高峰。