u-boot的任務是啟動核心，核心的任務是啟動應用程式。應用程式會涉及很多檔案和硬體操作（當然不會直接操作硬體），
比如讀寫檔案，點燈、獲取按鍵值。
對於應用程式的開發人員不要求去閱讀晶元手冊，了解硬體的構造。應用程式的開發人員在使用者空間直接使用open、read、
write等等這些被稱為系統呼叫的函式，通過這些函式進入核心空間，進而呼叫核心空間的驅動程式。
比如對於控制led燈的使用者程式與驅動程式，最簡單的實現方法是，應用程式中需要開啟led燈，就需要open函式,在核心中的驅動
程式中也有對應的led_open函式，這個led_open函式負責直接操作硬體，應用程式中要呼叫read函式讀取led燈的狀態的時候，核心中的驅動程式也有led_read函式。這是
應用程式與核心中驅動程式一種最簡單的對應方式。
那麼應用程式中的open、read函式最終怎樣呼叫到驅動程式中的led_open、led_read呢，中間有哪些東西。
我們首先寫乙個簡單的應用程式。
int main()
這些open、write函式在linux中稱為系統呼叫，是使用者態進入核心態的門戶。當處於使用者空間的應用程式呼叫這些系統呼叫的時候，
會進入核心空間執行。這些系統呼叫怎樣進入核心態呢？這些系統呼叫會呼叫一條彙編指令：swi 。在swi指令後面會跟著乙個值。這
個值用來表明是哪一條系統呼叫呼叫了該swi彙編指令，也就是說不同的系統呼叫呼叫swi指令，swi後面跟著的值都是不同的。這條匯
編指令會引發乙個叫做核心陷入的異常。引發核心異常會進入到乙個核心異常處理函式中。 核心異常處理函式會根據異常發生的原因，調
用不同的處理函式。異常發生的原因是根據swi後面跟著的值來決定的，比如說open函式執行swi，swi後面跟著的值是val1,read函式執
行swi，swi後面跟著的值是val2。核心中乙個稱為虛擬檔案系統的東西會根據swi後面不同的值去呼叫system_open或者system_read等
函式。再看上面的應用程式，我們點燈與開啟文字檔案，都是用的同樣的函式。但是點燈與開啟文字檔案的行為顯然不一樣。那麼誰來實現
這些不一樣的行為呢？
對於led燈，有led_open驅動程式。對於文字檔案存在於flash裝置上，也有對於的驅動程式。system_open、system_read最終會根據
開啟的不同檔案，找到底層的不同驅動程式的，然後呼叫驅動程式中的硬體操作函式比如led_open來實現對具體硬體裝置的操作。
這就是整個的字元裝置驅動程式框架。
驅動程式之 1 字元裝置 1
linux裝置驅動分三種，包括字元裝置驅動 塊裝置驅動和網路裝置驅動 其中本文講的字元裝置 如lcd 觸控螢幕等 只能按位元組流先後順序訪問裝置記憶體，不能隨機訪問 字元裝置的基本框架比較簡單 載入驅動時，呼叫入口函式 解除安裝驅動時，呼叫出口函式 應用程式開啟驅動裝置時，呼叫open函式 應用程式...
Linux裝置驅動程式學習（1） 字元裝置驅動程式
linux裝置驅動程式學習 1 字元裝置驅動程式 一 分配裝置號 1 對字元裝置的訪問是通過檔案系統內的裝置名稱進行的 dev ttys0 在核心中，include dev t 用來儲存裝置編號 包括主裝置號和次裝置號。由dev t獲得主次裝置號 major dev t dev minor dev ...
驅動程式之 1 字元裝置 3
基本排程關係 在應用程式中呼叫poll poll呼叫sys poll sys poll呼叫do sys poll do sys poll呼叫do poll do poll呼叫do pollfd do pollfd呼叫我們的驅動程式實現的my irq drv poll，my irq drv poll呼...