第二章 背景與相關研究
2.5 核心模式堆疊與使用者模式堆疊
在 Linux 系統中，每個應用程式都會有兩個堆疊，一個稱為使用者模式堆疊，另外 一個則是核心模式堆疊，使用者模式堆疊就是應用程式在使用者空間執行的時候所使用 的堆疊，而核心模式堆疊則是當應用程式進入核心空間時所使用的堆疊，當應用程式由 使用者空間進入核心空間時，SP 暫存器的值從使用者模式堆疊頂端的記憶體位置被置 換為核心模式堆疊的頂端的記憶體位址。
在 2.6 版本的核心之中，和過去不同的地方是，在過去版本的核心中，核心模式堆 疊的底端記錄的是該行程的行程描述子，而在新版本的核心之中，核心堆疊的底端只放 置了進入核心或返回使用者空間時必要的資料結構，這些資料結構在核心內被放在行程 敘述子的 thread_info 資料結構內，該資料結構可見圖 Fig.2-7。
Fig.2- 7 thread_info 資料結構 核心模式堆疊主要的作用有以下三點：
z 紀錄行程描述子中的線行程資訊 (thread_info) 。 z 儲存行程硬體環境 (hardware context) 。
z 核心函數呼叫及一般使用。
一般而言，核心堆疊的大小為 8k，其配置如圖 Fig.2-8 所示。
Fig.2- 8 核心堆疊 2.6 通知者串鍊
在 Linux 環境中網路介面卡驅動程式可能改變其名字或是一些旗標，甚至動態地插 入或是移除自核心之中 (當被編譯成模組時) ，在驅動程式而言，作這些動作是很單純 的事情，但是，當上層的協定堆疊或是核心程式有參照使用到這些驅動程式的時候，協 定堆疊或是其它核心程式就必須知道驅動程式的狀態改變，在 Linux 中通知核心其它部 分驅動程式有所改變所利用的機制稱為「通知者串鍊」 (notifier chain) [12]。
通知者串鍊為一個通用的核心內事件通知機制，很多事件都經由這個機制通知核心 的不同部分，圖 Fig.2-9 為其核心內的資料結構宣告，該結構表示了一個單向連結的串 鍊，其中：
z notifier_call 欄位是一個函數指標，為核心對於該事件的處理函數，其接受三個 參數：
self 為一個指向自身 notifier_block 的指標。
event 為事件的代碼
priv 為一個通用指標，所指的資料結構隨著串列種類的不同而定。
z next 為連結下一個串鍊的指標。
z 最後的 priority 欄位決定了你在串鍊中的位置，priority 欄位值設定的越大，會 被插入在串鍊的越前面，當事件發生的時候，註冊的處理函式也會越早被呼叫。
Fig.2- 9 notifier block 資料結構
網路事件使用的串鍊名稱為 netdev_chain，其在核心中的宣告為一個 notifier_block 的指標，當協定堆疊或是核心其它參照使用了驅動介面的部分想要得知某些事件的發生 時，便對該串列進行註冊，並且將自己的事件處理函數的指標放入 notifier_block 的 notifier_call 欄位，當事件發生後，便會照著串鍊順序依序呼叫其註冊的函數，網路使用 串鍊的示意圖如圖 Fig.2-10 所示。
Fig.2- 10 netdev_chain 示意圖
核心中針對 netdev_chain 也提供一些處理通知者串鍊的函數，這些函數包含了 call_netdevice_notifiers()、register_netdevice_notifier()以及 unregister_netdevice_notifier()；
call_netdevice_notifiers()會依序呼叫向 netdev_chain 註冊過的每一個處理函數；
register_netdevice_notifer()會向 netdev_chain 註冊，將傳入的通知者區塊 (notifier block) 加入串鍊當中；unregister_netdevice_notifier()則進行解除註冊的動作。
事件處理函數有固定的回傳值，call_netdevice_notifiers()接收到不同的回傳值後對於 之後的串鍊有不同的處理，各個回傳值的定義和串鍊的處理如表 Table.2-1 所示。
回傳值 描述 NOTIFY_DONE 已得到通知，但該事件無關緊要。
NOTIFY_OK 已得到通知，並且已處理完畢。
NOTIFY_STOP_MASK 已得到通知，並且停止對之後串鍊的呼叫。
NOTIFY_BAD 錯誤的通知。
Table.2- 1 事件處理函數回傳值 2.7 多網路的整合
現今的無線網路擷取技術大概可以分成兩種型態：無線區域網路(Wireless LAN，
WLAN)及個人行動電話的數據服務(如 GPRS、3G、和 PHS 等)。無線區域網路可提供 較高的傳輸速率，但移動性差和涵蓋範圍小，而數據服務提供較佳的移動性和較大服務 範圍，但傳輸速率較小。
由於目前各種無線接取技術的陸續出現，整合各種無線網路接取設備 (例如 WLAN、GPRS、3G、PHS) 於行動裝置之上已經是不可避免的趨勢；在 Cross Layer Design In 4G Wireless Terminals[13]此篇文章中提到在目前現有在使用的協定堆疊以及網路架 構都沒有納入多重介面的特性作為考量，在該篇文章之中也提及，在進行垂直換手的時 候 (vertical handoff) ，由於不同網路接取技術的特性相差很多，因此會對系統效能造成 很大的傷害，也由於如此，該篇文章認為應該存在著跨層 (cross-layer) 的通知機制，使 得驅動程式的事件可以傳達至網路堆疊的各層，如圖 Fig.2-11。
Fig.2- 11 跨層設計概念示意圖
根據 Mobile IP Applicability: When Do We Really Need It[14]的分類，行動性支援
(mobility support) 包含了：
z 位置管理 (location management) 。
z 換手管理 (handoff management) ，包含垂直和水平的換手。
一般來說，因為介面的控制和選擇是一種策略 (policy) ，通常由使用者空間的應用 程式來處理，而核心只提供控制介面的方法和機制，而在 Mobile IP Applicability: When Do We Really Need It 中則甚至主張行動性的支援應該由網路協定中更高層的部分來處 理，例如傳輸層 (transport layer) 或是應用層 (application layer) 。
而當位置管理或者是換手管理在應用層處理時，網路介面資訊的取得是不可或缺
芬蘭的赫爾辛基技術大學 (Helsinki University of Technology, HUT) 在 2005 年的 3 月 8 日的一個 study cluster 中也提出了和本論文類似概念的系統，該系統的架構圖如圖 Fig.2-12 所示。
該系統提供了一套使用者函式庫和應用程式介面 (API) 給應用程式，而在訊息的傳 達方面主要是利用一個使用者空間的常駐程式 (daemon) ，應用程式使用該系統提供的 應用程式介面和 VHO Daemon 之間建立 IPC (Inter-process Communication) 的通道，當 下層驅動程式有事件發生時，VHO Daemon 會先得知，之後利用 IPC 的方式通知應用程 式，而其提供的函式庫會依據發生的事件種類呼叫應用程式呼叫程式的回叫函數。
Fig.2- 12 HUT VHO Daemon 之系統架構 該系統中定義的事件有以下四大項：
z 系統驅動程式相關事件，其中包含了：
設備的新增以及移除
設備的連線狀態
其他設備資訊 z 換手通知。
z 其他 VHOAPI (Vertical Handoff API) 事件。
z Daemon 事件。
該套系統目前正在發展中，能找到的資料並不多，關於其驅動程式層的支援則是使 用 Ericsson 發展的 L2 機制，不過相關的資料我們無法取得，該系統和本論文所發展的 系統相異之處在於：
z 使用 IPC 作為事件通知機制的基礎。
z 處理函式的呼叫全在使用者空間完成。
z 支援 Java 平台
第三章 驅動程式層網路事件通知機制設計與架構
在本章中，將會敘述實作本論文之系統概觀以及各元件的設計原理以及原則，其 中，包含了網路相關事件的定義以及其代表的意義，這些事件何時發生及核心何時對其 作相關的處理，訊息的產生 (generation) 和傳達 (delivery) ，以及在使用者空間和核心 空間之間切換所使用的方法。
及的設計於 Intel x86 平台實做出一套完整的系統。 叫 (callback) 函數，當有事件發生時，系統的排程器 (scheduler) 便會優先先執行註冊 過網路事件的行程。
Fig.3- 1 系統元件架構和關係 3.3 系統呼叫的設計
本系統允許使用者利用系統呼叫註冊的回叫函數，以下敘述該系統呼叫的使用方法 以及設計。
本系統所實作的系統呼叫之相關宣告如圖 Fig.3-2 所示。
Fig.3- 2 系統呼叫相關宣告
其中，第一個參數代表系統呼叫所欲註冊的事件代碼，第二個參數則是一個沒有回 傳值的函數指標，當此參數被設定為空指標 (NULL value) 時，代表解除註冊該事件的 監聽，第三個參數為一個全域變數的緩衝區 (buffer) 位址，當相關事件發生時，核心會 將發生事件的網路介面名字填入這個緩衝區中，最後則是該緩衝區的大小。
3.4 網路相關事件之定義
當程式寫作者想要寫作一個異質網路的管理平台時或這是當程式寫作者單純的想 要將其原本的應用程式加上行動性的支援時，最難處理的其中一個部分便是網路介面的 管理。使用者層的程式為了要得知下層驅動程式的狀況，必須不停的利用系統呼叫詢問
下層的驅動程式狀態，在本系統中，將這些類似輪詢的下層驅動程式得知方式改變為事
NETDEV_UP 0x0001 啟動某個網路介面。
NETDEV_DOWN 0x0002 關閉某個網路介面。
NETDEV_REBOOT 0x0003 當網路介面偵測到硬體錯誤且需要重新啟動。
NETDEV_CHANGE 0x0004 驅動程式旗標有改變。
NETDEV_REGISTER 0x0005 網路驅動程式被插入核心中。
NETDEV_UNREGISTER 0x0006 網路驅動程式由核心中移除。
NETDEV_CHANGEMTU 0x0007 網路介面更改 MTU (Maximum Transfer Unit) 。 NETDEV_CHANGEADD 0x0008 網路介面之硬體位址改變。
NETDEV_GOING_DOWN 0x0009 在驅動程式的 IFF_UP 旗標被清除之前。
NETDEV_CHANGENAM 0x000A 驅動程式改變其名字。
Table.3- 1 系統內定義的網路驅動程式事件
兩者對於核心的網路協定堆疊來說並沒有特別意義，而第三者在核心的定義來說並非驅 (bit array) 儲存，而對於發生事件的紀錄，我們在系統的行程敘述子 (process descriptor) 中新增一個事件串列，該串列用以記錄行程所註冊過，且已經發生過的網路驅動程式相 關事件。
當系統中有網路驅動程式事件發生後，程式將會將對應的事件及其相關訊息轉換成 一個事件描述子 (event descriptor) ，並且依據事件發生的順序將其插入對該事件註冊過 之行程敘述子中的事件串列中，如此一來，便可以得知重複事件的發生以及其先後發生 的順序。
3.6 事件的產生
在章節 2.2.3 中定義了事件的產生 (generation) 以及傳達 (delivery) 的不同，對於 網路事件的產生方面，我們利用了系統內的網路驅動程式通知者串鍊的機制並且對其擴 求清除 IFF_UP 旗標，並且呼叫通用驅動程式層的 dev_close()函數，在這些動作完成之 後，通用網路驅動程式層中的 dev_close()函數會使用通知者串鍊通知核心其它部分該事
件的發生。
在本系統中，仍然利用通知者串鍊來達到事件提醒的基礎，也就是說，我們實作了 一個事件處理者 (event handler) ，該事件處理者會將核心內用來通知其它網路協定部分 的網路通知者串鍊機制延伸至使用者空間使用；當有網路驅動程式相關事件發生後，事
在本系統中，仍然利用通知者串鍊來達到事件提醒的基礎，也就是說，我們實作了 一個事件處理者 (event handler) ，該事件處理者會將核心內用來通知其它網路協定部分 的網路通知者串鍊機制延伸至使用者空間使用；當有網路驅動程式相關事件發生後，事