一種共享內存的END驅動設計

????????1 引言

　　本文提出的SM END驅動模型為分布式多處理器系統(tǒng)間提供了一種通過CompactPCI總線而進行網(wǎng)絡通信的方式，使得系統(tǒng)兩側的上層網(wǎng)絡應用程序可以通過標準網(wǎng)絡接口與對側系統(tǒng)進行透明的網(wǎng)絡通信。

??????? END是嵌入式實時操作系統(tǒng)VxWorks中工作在數(shù)據(jù)鏈路層的一種網(wǎng)絡驅動模型，該模型定義了與MUX層交互的標準接口，用戶只需要根據(jù)特定的網(wǎng)絡接口硬件特性按要求提供這些接口即可實現(xiàn)END層與網(wǎng)絡協(xié)議層的通信。END驅動模型的存在，使得VxWorks可以滿足嵌入式產(chǎn)品對各種網(wǎng)絡接口硬件的適應性和通用性，也使得通過軟件模擬的滿足END驅動特性的虛擬網(wǎng)絡接口成為可能。

　　在基于總線的分布式多處理器系統(tǒng)中，SM是應用較為廣泛的實現(xiàn)多處理器之間的一種通信手段。VxWorks操作系統(tǒng)也提供了對共享內存的支持，通過駐留在主系統(tǒng)或從系統(tǒng)中的共享內存，分別運行在主從系統(tǒng)上的兩個任務可以像在單一系統(tǒng)中的兩個任務一樣進行透明的進程間通信。

　　基于SM的END驅動，從軟件上將共享內存模擬為一個虛擬的網(wǎng)絡接口，從而可以提供諸如IP over PCI等功能特性，使得上層的應用程序可以通過CompactPCI總線進行標準的網(wǎng)絡通信。

　　2 END機制分析

　　VxWorks中的增強型網(wǎng)絡驅動END是一個使用MUX功能來與網(wǎng)絡協(xié)議進行通信的數(shù)據(jù)鏈路層驅動模型。MUX是數(shù)據(jù)鏈路層與網(wǎng)絡層之間的接口， VxWorks提供MUX層以支持數(shù)據(jù)鏈路層與網(wǎng)絡層的相互獨立性。

　　在VxWorks的這種架構下，網(wǎng)絡層協(xié)議和數(shù)據(jù)鏈路層驅動程序不能直接通信，而必須通過MUX。網(wǎng)絡層要調用數(shù)據(jù)鏈路層上的驅動程序以發(fā)送數(shù)據(jù)，那么網(wǎng)絡協(xié)議就需要調用相關的MUX例程，同樣鏈路層上的驅動程序需要訪問網(wǎng)絡層(IP或其他協(xié)議)時，也需要調用相關的MUX例程。圖1給出了網(wǎng)絡層、MUX層和驅動層三者之間的接口。

　　圖1 協(xié)議層、驅動層與MUX層的接口

　　END設備需要初始化才能工作。初始化的第一步是向系統(tǒng)注冊END設備，接著應該在系統(tǒng)初始化時通過MUX層接口加載END設備，然后可以通過MUX層接口啟動END設備驅動或將網(wǎng)絡協(xié)議綁定到END設備。在中斷模式下時，END層的啟動例程在啟動設備的同時需要連接中斷服務程序，當END設備收到數(shù)據(jù)包而引起中斷時，會調用此中斷服務程序進行數(shù)據(jù)接收工作;另一方面，網(wǎng)絡協(xié)議也可以通過MUX層接口將它自身綁定到END設備以實現(xiàn)輪詢模式的工作方式。

　　當VxWorks收到由數(shù)據(jù)到達引起的中斷時，它調用由END啟動例程注冊的中斷服務程序。該中斷服務程序將數(shù)據(jù)幀從本地硬件傳遞到系統(tǒng)緩存，并通過回調函數(shù)將此數(shù)據(jù)緩存?zhèn)鬟f到MUX層。MUX層接收例程進而調用協(xié)議層的接收函數(shù)將數(shù)據(jù)緩存?zhèn)魉偷綉贸绦颉?/p>

　　當上層應用程序需要向外發(fā)送數(shù)據(jù)時，通過協(xié)議層的接口調用MUX層的發(fā)送例程，MUX發(fā)送例程通過回調函數(shù)將數(shù)據(jù)緩存?zhèn)鬟f給END驅動，END驅動進而將要發(fā)送的數(shù)據(jù)緩存復制到設備的發(fā)送隊列，當設備收到發(fā)送數(shù)據(jù)中斷時，中斷服務程序調用發(fā)送函數(shù)將設備發(fā)送隊列中的數(shù)據(jù)發(fā)送出去。END機制下的數(shù)據(jù)接收和發(fā)送過程分別如圖2(a)、2(b)所示。

　　3 SM END設計與實現(xiàn)

　　從上面對END驅動工作原理的分析過程中可以看出，在這樣一種模型下，END驅動程序和上層協(xié)議之間是透明的，它們并不了解彼此的內部信息，而是通過MUX層這個接口來進行間接地通信。保持這種透明性最大的好處是便于移植，可以很容易地增加一些新的END驅動程序或協(xié)議而能夠保持透明的通信。正是基于這一點，本文基于一種共享內存機制，將共享內存作為一種虛擬網(wǎng)絡設備，設計了基于共享內存的END驅動。基于共享內存的END驅動不再利用物理網(wǎng)絡設備的中斷服務程序進行數(shù)據(jù)的收發(fā)，而是直接使用底層共享內存機制的收發(fā)例程完成數(shù)據(jù)的收發(fā)，從而實現(xiàn)主從系統(tǒng)之間的網(wǎng)絡通信方式。

　　具體來看，SM END模型可以分為三部分，初始化、加載與啟動。SM END的初始化與標準END的初始化步驟相同，具體方法在稍后的實現(xiàn)部分說明。加載SM END設備，即向系統(tǒng)注冊SM END驅動模塊，也與標準END的加載過程相同。啟動部分有區(qū)別，因為共享內存并不是真實的物理網(wǎng)絡設備，因此它不能像物理設備那樣通過中斷觸發(fā)數(shù)據(jù)的收發(fā)。本文利用底層的共享內存驅動機制實現(xiàn)數(shù)據(jù)的接收，即在啟動SM END驅動時向底層的共享內存驅動模塊先注冊一個回調函數(shù)(SmEndCallBack()函數(shù))，底層的共享內存驅動收到數(shù)據(jù)后，再調用此前SM END向其注冊的回調函數(shù)，進行數(shù)據(jù)的接收處理。在發(fā)送數(shù)據(jù)時，SM END驅動可以直接調用SM驅動的發(fā)送例程進行數(shù)據(jù)發(fā)送。基于SM END的數(shù)據(jù)收發(fā)流程如圖2(c)、2(d)所示。

　　圖2 數(shù)據(jù)接收和發(fā)送流程

　　需要指出的是，本文所提出的SM END模型是獨立于底層具體的共享內存機制的，這樣，在編碼實現(xiàn)SM END驅動時，只需要調用底層具體的共享內存機制向上提供的發(fā)送和接收接口函數(shù)就能實現(xiàn)不同共享內存機制下的SM END驅動。

　　SM END的實現(xiàn)上，需要完成兩部分任務，一部分為SM END設備的初始化，一部分為SM END需要提供的接口函數(shù)。SM END設備的初始化部分，只需要在VxWorks提供的框架下進行簡單的操作即可，具體來講有兩步工作要做：第一，在系統(tǒng)中添加END機制模塊，即在BSP目錄的config.h文件中增加宏INCLUDE_END;第二，向系統(tǒng)注冊SM END設備，即在BSP目錄的configNet.h文件的全局變量endDevTbl中增加SM END設備對應項。

　　SM END驅動需要提供的接口函數(shù)必須與標準END驅動接口函數(shù)一致，表1列出了SM END驅動所提供的全部接口函數(shù)。其中，SmEndLoad()函數(shù)完成向系統(tǒng)加載SM END驅動模塊的功能，具體來說，它需要創(chuàng)建并初始化SM END數(shù)據(jù)結構，并為SM END驅動模塊分配內存以緩存發(fā)送和接收的數(shù)據(jù)包。SmEndStart()函數(shù)啟動SM END設備，內部實現(xiàn)是向底層的共享內存驅動模塊注冊回調函數(shù)，當共享內存驅動收到數(shù)據(jù)后再調用此回調函數(shù)進行數(shù)據(jù)包的接收。SmEndSend()函數(shù)通過調用SM模塊的發(fā)送例程實現(xiàn)END層的數(shù)據(jù)發(fā)送功能。SM END驅動必須能夠支持多播，SmEndMCastAdd()、SmEndMCastDel()和SmEndMCastGet()實現(xiàn)SM END設備對多播的支持。此外，SM END驅動還提供對數(shù)據(jù)包的操縱函數(shù)和I/O控制等等支持。

　　表1 SM END驅動的接口函數(shù)列表

　　4 結束語

　　本文在詳細分析了VxWorks中END驅動工作原理的基礎上，結合實際需要，提出了基于共享內存的END驅動模型，該SM END驅動模型獨立于具體的共享內存機制，在一種共享內存機制下實現(xiàn)了SM END驅動。