OS課程心得

寫完這篇文章，這學期的OS課程也就正是結束了，因此在這邊抒發一下上課的感覺。

首先，這學期最另大家詬病的就是，老師在期中之前一直動不動就請假，而導致課程進度不斷的delay。有時候臨時請假時，大家去上課之後才發現停課，一整個心情相當的差，而且當假越放越多時，就會很不想去上這堂課。

再來由於課程delay嚴重的關係，因此期中的範圍相當的少，但到期末之後一直瘋狂的補課，趕進度，使得期末範圍變得相當的大，讓我在準備期末時感覺要念得東西太多了，很難負荷。因此這學期的進度拿捏真的不是很好。

在實習部份，其實實習作業要做的練習是相當的簡單。然而，要搞出環境出來去相當的困難。以練習KGDB為例，我平常在用的linux環境是ubuntu，但這次作業要弄的環境卻在fedora上，因此還要花一番功夫去設定環境。然而，有人發現fedora 10沒辦法跑，這又導致一些人灌了以後又要重新灌一次fedora 8。整個做作業時間都浪費在上面，讓我覺得這個作業是要讓我們練習重灌嗎？

助教方面的話，由於每個作業是某個助教負責，這樣子或許對他們有利，因為只要負責一部分就好了。但對我們來講，當找不到該名負責的助教時，要問其他助教相關的事，就沒辦法回答有關的問題，因此讓人覺得助教們相當的混。更別說作業成績到期末才一一批改完，之前交了作業都不曉得到底有沒有收到。

雖然老師教學上可以感受的到很想要認真的教給大家東西，不過由於以上種種原因，使得大家感覺並不是很好，甚至有些人一直在罵，這是相當可惜的部份。希望日後能夠有所改進。

嵌入式軟體課程結束

在今天，把該有的報告生一生之後，這學期的嵌入式軟體課程就正式結束了。然而相當遺憾的是，我們的期末專題最後仍是沒辦法趕出來。

分一下專案失敗的原因：

1. 時間的規劃：我們專題動手開始做的時間相當的晚，快到期末時才開使趕工。
2. 之前文章有提到，舊版linux上編譯的問題，再這個部份真的是花上了超多的時間，即使到現在，有些編譯出來的的執行檔去kernel上跑時，會發生一些莫名其妙的問題出現，要解決相當的困難。
3. 3.debug環境；在嵌入式系統上要debug相當的困難，而且也要花不少時間，像是每當系統改了一部分以後，需要重新燒進板子內，而燒的時間會需要好幾分鐘，因此debug的效率非常慢。
4. 4.library的問題：板子開發商給library有一些嚴重的bug，這導致我們把程式編譯好以後，要去執行時會產生不預期的錯誤出現，這部份要trace也相當的困難。而我們想去找較其他版本的library來編譯時，首先也會產生舊版的gcc不支援，然後修好以後，結果也沒有改善，因此最後這部份就以失敗告終，而專案就到這邊沒辦法進行下去了。

在做這個專案時，遇到很多的挑戰，這些都不是上課有辦法教得東西，即使OS讀在熟，遇到時也往往不知道怎麼解決，畢竟可能不是OS寫錯，而是其他部份產生的問題。然而經過這次的經驗，也讓我覺得光會死讀書是不行的，必需要有時做的經驗才能真正瞭解到知識。

Kernel panic

我在做嵌入式軟體的專案時，最常出現就是Kernel panic的問題。

Kernel panic的意思是指，OS遇到了一個內部的錯誤，這個錯誤並沒辦法被安全的修復起來，而導致沒辦法繼續運行，可能必須重新啟動才行。有點像Windows 的藍屏死機。

而造成Kernel panic的原因，大多是是擴充記憶體出現問題，但亦有可能是其他硬體產生。在嵌入式系統環境下，可用的memory空間往往不夠，因此一旦kernel編譯出來，必需要去指定該用多少空間，不然一旦超出範圍，就一下子就當了。

Kernel panic產生時，往往很難知道到底哪邊出了錯，因此我在做debug的時候，只能利用debug工具，將產生的組語一行一行trace下去，看看到底執行到哪時會出錯。這很花時間，然而也不知道有什麼比較好的方式可以使用，因此是一項相當麻煩的問題。

態度

這學期我的室友面臨了要被兩次二一退學的危機，而我則是感覺這學期也會被二一。為什麼會面臨如此的窘境呢？關鍵還是在於態度。

大三下是大學時期最重要的一段時間，因為面臨了未來的抉擇，像是專題要做什麼，有沒有計畫要考研究所等。這都是在這學期就要決定的時刻，一超過這時期，要再來補救就很困難了。而我雖然知道這些，也不斷去煩惱該走哪條路，可是實際的作為卻是懶懶散散，跟以前一樣。明明是該振作的時期，卻一直白白的浪費下去。也就是說自己的決心不夠，展現不出自己的態度出來。

以上OS課為例，每次去聽課的時候，總是很容易分心，想別的事情。或者因為在中午時段，特別的想睡覺，常常就這樣趴下去了，因此老師再講什麼也基本上學不到什麼東西，這樣子的結果就導致了期中期末準備起來特別的辛苦，因為有些東西要有聽過才會好理解，光靠投影片很難知道概念是什麼，其結果就是考試都考得很慘，也因此面臨的被當的危機。

回想大一時期，那時候還滿拼的，作業都會準時交，也從來沒有在蹺課，上課時也會專心聽老師在講什麼，因此大一時期是我學到最多東西的時候。比對現在，這樣子的態度實在不行，因此當務之急是要找為當時的態度，重新取回對知識學習的熱誠，這樣面對未來時才不會陷入泥沼，誤入歧途。而老實說，目前我對未來的規劃是相當的徬徨的。

CUDA

NVIDIA 在自家的顯卡上，設計了這一種程式語言，目的是為了可以利用顯卡上的GPGPU (General purpose graphics processing units) 泛用圖形處理晶片，來進行平行化的運算。GPGPU 可以把他當成是一個小型的cpu，再目前顯卡上，GPGPU 的數量往往很多，有些高達上百顆，因此利用這些GPGPU來進行平行化運算，效率會快上許多。

在稍微摸過一下CUDA後，覺得CUDA 寫作並不困難，困難之處在於如何最佳化，它需要了解不少硬體的細節。一般而言未最佳化的程式在 GPGPU 上面執行，可以比傳統的 CPU 快上 5~10 倍，而最佳化過的程式，往往還能再增速 5~10 倍，達到 25~100 倍的效能。

CUDA 和傳統 C++ 最大的差異在於「平行化的程式設計」vs.「序列化的程式設計」，例如傳統上透過迴圈執行數千次的程式碼，在 CUDA 上就可以將它拆解成數百個同時執行的執行緒，每個執行緒只執行十幾次而己，因此產生數十到數百倍的效能。

CUDA 是在傳統 C++ 的基礎上，加入一些延伸語法，以及輔助的函式庫，而形成的一
種程式語言，一般而言只要熟悉 C 或 C++，就很容易上手，編譯好的程式碼，也可以跟其它語言做不錯的聯結。

不過由於是NVIDIA自己設計的，因此目前只有他們家的顯卡可以支援，且也不是每一種顯卡都能跑，至少要8系列以上才有辦法跑，限制滿多的。因此也有同類型的OpenCL發展起來，OpenCL是OpenGL發展起來的，因此是一套免費的工具，並且會制定公開的規格，因此目前我比較看好OpenCL就是了。

Deadlock

今天去看了一下改好的嵌入式軟體的期末考卷。檢討一下，看看有哪些觀念還不太清楚的。其中有一題是問只用一個semaphore時，有沒有可能發生Deadlock的問題？此題的答案為有可能發生Deadlock，不過助教給的解釋是當call semaphore lock時，沒去unlock就會發生。在當時聽到時覺得不太滿意，不過其實Deadlock的條件已經想不太起來了，因此回去找一下Deaklock的定義，看看還有哪些情況會發生。

Deadlock發生的4個條件：
1. Mutual Exclusion: At least one resource must be held in a non-sharable way.
2. Hold and Wait: A process must be holding a resource and waiting for another.
3. No Preemption: Resource cannot be preempted.
4. Circular Wait: A waits for B, B waits for C, C waits for A.

看完以後，就想到要是自己去等自己的話，也會發生Deadlock，或者包在semaphore裡面的是一個無窮迴圈。也就是一進去就出不來的情況下，就會發生。因此一個semaphore的確會發生Deadlock的問題。

Ubuntu 漫畫化？！

看到後噴茶，連這種東西也能畫成漫畫。

うぶんちゅ！ (Ubunchu) 是由日本的插畫家/漫畫家瀬尾浩史先生所創作、描繪，用以介紹 Linux 作業系統 Ubuntu 發行系統的校園喜劇漫畫。