1.本文目的

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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