1.本文目的
隨著RT-Thread Smart微內核發(fā)布會的臨近,對于開源社區(qū)以及國產(chǎn)RTOS比較關注的人或許早有耳聞。RT-Thread要發(fā)布微內核操作系統(tǒng)了。從去年的華為提出鴻蒙微內核到目前為止,都未曾真正見到一個微內核系統(tǒng)面向大眾。從真正的開發(fā)者角度來看,或許真正的關注點不在于多少先進技術的提出,而實際的關注點在于是否好用,是否能夠快速高效的開發(fā)出穩(wěn)定的產(chǎn)品,是否用上了之后能夠減少自己的工作量。本文主要從微內核開發(fā)的思維角度出發(fā),談一談RT-Thread Smart以及我個人進行微內核開發(fā)工作的所思所想。
2.微內核的差異性
內核是操作系統(tǒng)中管理資源的核心部分,它充當著計算機程序與硬件之間橋梁。
其實在程序運行時,用戶態(tài)程序想要訪問外設,必須要通過內核進行資源調度,然后進行統(tǒng)一的管理?,F(xiàn)在許多CPU中,最基本的都會有用戶模式和超級管理員模式兩種。用戶程序首先必須要有可以自己管理的一段內存空間,進行業(yè)務邏輯的設計,如果要使用到共享資源或者硬件資源時,那就需要通知內核,此時內核進行調度和分配,在合適的時機給申請資源的應用程序。如果訪問特殊的寄存器,這時候,還需要切換CPU的模式,從而訪問超級管理員才能使用的寄存器。
這種權限的控制核心都是由內核進行,用戶態(tài)程序申請訪問內核資源的時候,通常是通過軟件中斷的形式實現(xiàn),這會導致硬件的中斷處理程序將控制權轉移到作為操作系統(tǒng)一部分的適當?shù)闹袛嗵幚沓绦蛏?,在進程中將模式位轉換為內核模式。中斷處理程序檢查生成了哪個中斷,如果合適,檢查附加參數(shù)(通常通過寄存器傳遞),然后調用適當?shù)膬群朔绽虂硖幚硐到y(tǒng)調用請求的服務。
此時如果用戶程序訪問了非法指令,或者訪問了本不該自己訪問的東西,也會產(chǎn)生軟件中斷,從而將事件交給內核處理,內核進行保存錯誤日志,并負責清理垃圾。
上述也僅僅介紹了內核態(tài)與用戶態(tài)的基本工作流程,微內核基本也是沿用了這套思想,但是微內核體現(xiàn)的正是這個微的特定。為了體現(xiàn)微這個特點,微內核一般只會提供最少的進程和內存管理的服務,客戶端程序與應用程序只在用戶地址空間之間進行消息的傳遞,這樣并不會影響內核的功能,但是這樣的方式會大大增加消息傳遞的負載,也就是說,大量的消息傳遞也會降低系統(tǒng)的運行性能。但這些犧牲帶來的好處也是顯而易見的,對開發(fā)者來說非常的方便,不用過分關注內核的穩(wěn)定性問題,只需要好好處理上層的業(yè)務邏輯即可。
3.微內核該怎么寫應用程序?
微內核的應用程序部分一般不需要過度的去關注內核部分的代碼,就像我們進行Linux開發(fā)應用程序一樣。首先應該充分的相信微內核內核部分的可靠性,如果一出問題就總是懷疑內核是不是有BUG那就不太適合進行微內核的開發(fā)工作。我們在開發(fā)Linux的時候,遇到問題,總不會把Linux的整個代碼再review一遍,這樣是費力不討好。
所以進行微內核的開發(fā)工作,首先需要知道微內核提供的編程規(guī)范,以及所提供的API函數(shù)進行程序設計。其實在C語言中,也是會提供一些標準庫函數(shù)的,比如RT-Thread Smart中提供的musl庫等等。當然還有不同微內核系統(tǒng)中所提供的專用的API,比如對RT-Thread比較熟悉的人,在上手RT-Thread Smart時,也能夠找到很多之前用到的函數(shù)API的接口的影子。
而APP的編譯是獨立的,只需要交叉編譯工具鏈,將程序鏈接到指定的入口地址,無論是通過makefile還是scons或者CMake都做不做限制,編譯出來的程序,微內核通過加載器加載到內存中去執(zhí)行程序。
另外編寫應用程序需要注意的是不同線程之間的消息傳遞機制,以及線程與進程之間的關系。這個是非常值得關注和思考的問題。
4.微內核的效率和實時性怎么樣?
我覺得微內核的實時性是弱于RTOS強于LInux的,之所有有這樣的結論,是因為微內核確實會存在大量消息傳遞機制傳遞消息的問題。對于直接進行處理事件的RTOS來說,這樣的方式必然會降低系統(tǒng)響應的速度。如果業(yè)務邏輯簡單倒是看不到很明顯的差異,但是一旦涉及到任務量大,應用程序很多的情況時,內核的負載太大了。
例如在用戶態(tài)進行網(wǎng)絡協(xié)議棧的處理上來說,如果說驅動在內核層,網(wǎng)絡協(xié)議棧在用戶層,數(shù)據(jù)將直接從內核驅動過來,然后通過消息傳遞機制比如共享內存?zhèn)鬟f到用戶態(tài),用戶態(tài)接收到通知,然后再拷貝數(shù)據(jù),處理數(shù)據(jù),然后通過系統(tǒng)調用,又將處理好的數(shù)據(jù)傳遞到內核層。這個過程涉及到太長的鏈路,一定會影響系統(tǒng)的性能。但是如果驅動在應用層,那也需要大量的消息傳遞機制來確保兩個進程間的通信的迅速以及準確??傮w說起來,對于目前高性能的處理器來說,性能一般不是太大的瓶頸,架構的穩(wěn)定與系統(tǒng)復雜度也是需要好好均衡的,魚與熊掌不可得兼,舍魚而取熊掌者也,至于其中的利弊,個人來做評判與選擇。
5.如何客觀的評價RT-Thread Smart混合微內核?
從我的角度去看這個東西,或許是用瑕不掩瑜這個詞語概況比較恰當一點。凡事在開始階段,都是在摸著石頭過河,沒有人會知道這個東西的真正面目是什么,也沒有人徹底的能夠描繪出它的全貌,所以開發(fā)的過程一步一步的進行的是挖坑再填坑的過程,剛開始沒有輪子,然后慢慢有了一個輪子形狀的東西,能轉但是很奇怪,因為并不方正。然后慢慢的砍成一個方形的,之后慢慢磨,終于變成圓形的了,這時候就走的很順暢了。我說的上述過程大概就是我做了一點微內核的開發(fā)工作的心路歷程吧。
真正的做下來,沒有什么嘗試是毫無意義的。造不如買,買不如租這種思維模式,收益的也只是眼前,從長遠的大趨勢上來看,唯有走在最前面的人,才能看得到最好的風景。這次RT-Thread Smart 混合微內核的發(fā)布,具體能夠有哪些東西值得關注,我后面再慢慢細說。我不敢說這個是一個極其好用的東西,但是我覺得至少走出了第一步,這也是一個突破。更多的功能完善,更加穩(wěn)定的實現(xiàn)細節(jié)可能需要的是更多的努力吧,還有需要更多人的智慧,才能不斷推進技術走向更高的高峰。
-
微內核架構
+關注
關注
0文章
5瀏覽量
6539 -
微內核
+關注
關注
0文章
57瀏覽量
13430
原文標題:微內核進行開發(fā)工作究竟是怎樣的感受?
文章出處:【微信號:Embeded_IoT,微信公眾號:嵌入式IoT】歡迎添加關注!文章轉載請注明出處。
發(fā)布評論請先 登錄
相關推薦
評論