riscv

故事是這樣子的，上一章的結尾雖然寫了：

下一步就可以開始初始化 kernel 的 process table 啦。

但事後發現，原來還有東西比建立 process 更重要的，那就是先把 trap 給建立好：

上次我們發佈 rrxv6 的文章，已經是八月的事情了，大家可能以為我已經棄更了？ 其實這個小弟也有在認真反省，在我停更 rrxv6 這段期間剛好看到傳說中的 jserv 大神貼文：

到底高等教育出了什麼問題？為何很大比例的電機資訊畢業生，沒辦法堅持把事情做好？
思索九年，我想自己理解部分的原因：扎實地做事難以獲得短期的讚揚，而台灣許多人無法等到長期效益落實的那刻……。

想說靠北這不就是在說我嗎QQ，一直以來都沒把事情做好，像 ruGameboy 最後就被我棄更了，現在變成十八般武藝樣樣稀鬆只能混口飯吃。

故事是這樣子的，雖然在上上篇的 Context Switch 我們曾經預告過因為 static 的問題， 可能要停更一段時間，但後來沒停更，static 問題很快就用 spin 提供的 no_std Mutex 解決了。
不過，no_std Mutex 雖然解決 static 不用手爆 constructor 的問題，同時卻產生了另一個問題：stack overflow。

因為呼叫 static variable constructor 會用到 os process 的 stack，static variable size 一大，os process 的 stack 就會被吃乾抹淨。
所以問題來了，我們必須要儘可能的縮小 static variable 的尺寸，像上篇把 process 的 context 全塞在裡面是不可能的 （為了讓 code 動起來我把 process 數量降到剩 2 個），因此下一步就很清楚了，必須挑戰作業系統裡一大難題：記憶體管理。

故事是這樣子的，上一篇我們使用 unsafe 來操作 global variable，並用這個做到 cooperative multitask， 很不幸的這個方法是不行的，包括幾個問題：

1. 身為 Rustacean 非不得已怎麼可以用 unsafe 呢？這樣狂用 unsafe 根本離經叛道
2. 當 static 的型態複雜到一個程度的時候，這樣手爆資料型態絕不是方法，一定要使用 default 才行。

稍微搜尋一下之後，果然找到一個可行的方案，用社群提供的 crate spin ， 可以在 #[no_std] 的狀況下提供 Mutex（有關如何實作 Rust Mutex，' 可以參見這篇文章 ）

首先先預告一下，這篇有可能會是本系列連續更新的最後一篇，更新完這篇之後我要去閉關念書（看 code）一段時間，原因我等等會說明。

上一篇我們提到在 rust 裡面實作實際對應實體暫存器的程式碼，同時也確定這些程式碼可以真的提供無額外成本的虛擬化， 這篇順著 mini-arm-os 的腳步，來實作 Context Switch；timer 的設定我們先跳過，畢竟這篇還不會實作到 timer interrupt 觸發 context switch。

上一回我們看到我們用 rust 寫了一些底層的 code，當然，這個寫法並不好看，有沒有更漂亮的寫法呢？ 這篇參考了 rust cortex-m 的寫法， 以及強者我同學在 Google 大殺四方的小新大大分享的文 A guide to better embedded C++。

上一篇我們成功讓 assembly 執行一個 jump 跳進 Rust 函式，但這樣其實一點用也沒有，畢竟只會 loop 的作業系統並不是一個很好的作業系統； 這篇我們就參考一下 xv6 的開機流程，然後試著用 Rust 重新實作。

故事是這樣子的，大概六月中的時候，小弟因緣際會空出一些時間，因為武肺持續三級警戒只能待在家裡，除了打混摸魚之外順便看了一下別人寫的翻譯文 embedonomicon，翻完之後看看 rust cortex-m 都被人做走了，那有什麼東西可以玩的呢？
有一天晚上上床的時候就想到了，剛好最近在想看一下 MIT 教學用的作業系統 xv6，看看究竟可以用的作業系統是怎麼實作的， 而 xv6 本來是針對 x86 處理器，最近才被移植到新的 riscv 處理器上， 也有人把 xv6 用 rust 重新實作 ，那我是不是能如下圖，填上這個表格最後一個空格呢？