移植Windows裝置驅動程式至Linux之可行性研究

全文

(1)國立交通大學電機學院與資訊學院資訊學程碩士論文. 移植 Windows 裝置驅動程式至 Linux 之可行性研究. Feasibility Study for Porting Windows Device Drivers to Linux. 研究生：謝清茹指導教授：張瑞川. 教授. 中華民國九十五年六月.

(2) 移植 Windows 裝置驅動程式至 Linux 之可行性研究 Feasibility Study for Porting Windows Device Drivers to Linux. 研究生：謝清茹. Student：Ching-Ju Hsieh. 指導教授：張瑞川. Advisor：Ruei-Chuan Chang. 國立交通大學. 電機學院與資訊學院專班資訊學程碩士論文. A Thesis Submitted to Degree Program of Electrical Engineering and Computer Science College of Computer Science National Chiao Tung University in Partial Fulfillment of the Requirements for the Degree of Master of Science in Computer Science June 2006. Hsinchu, Taiwan, Republic of China. 中華民國九十五年六月.

(3) 移植 Windows 裝置驅動程式至 Linux 之可行性研究. 學生：謝清茹. 指導教授：張瑞川. 國立交通大學電機學院與資訊學院資訊學程﹙研究所﹚碩士班. 摘. 要. 目前市面上最受歡迎的作業系統有二：一為 Windows 作業系統，另一則為 Linux 作業系統。雖然後者支援的應用程式眾多且為免費的作業系統，但礙於 Linux 平台能支援的驅動程式較少，使用者裝置無法在該平台得到和 Windows 平台相同的支援，也因此大大的降低了一般使用者在 Linux 平台的普及率。此外，近年來嵌入式裝置大量的被開發應用，生活中常見的裝置包括數位相機、印表機、手機等各式各樣的產品不斷推出，這些裝置都需要硬體廠商開發驅動程式才能與電腦的作業系統互通，因此能快速開發穩定且支援多平台的驅動程式成為各家廠商相互競爭的關鍵一環。開發 Windows 驅動程式，除了要了解裝置的硬體規格以及整個裝置的功能需求外也要了解整個 Windows 驅動程式模型，這些就已經花掉一個程式設計師相當多的時間來學習，如果再加上開發 Linux 平台的驅動程式可能要耗費更多的人力及時間，也影響產品上市的時間。其實要開發同一裝置在兩個平台的驅動程式，除了平台上驅動程式模型不同外，其它的硬體規格及功能需求應是一樣的。因此本研究以 Windows 2000 及 Linux 2.6 作業系統為主，來探討兩種平台移植的可行性，並使用 Lex/Yacc 來建置一個可擴充的模型讓不同的裝置及作業系統可以在此建立對應及轉換，以期能為兩個平台的驅動程式開發者節省開發時間。關鍵字: 移植、Windows 2000、Linux 2.6、裝置驅動程式模式、驅動程式產生器、Lex/Yacc. i.

(4) Feasibility Study for Porting Windows Device Drivers to Linux. Student: Chin-Ju Hsieh. Advisor: Ruei-Chuan Chang. Degree Program of Electrical Engineering and Computer Science National Chiao Tung University. ABSTRACT Currently, the most popular operating system has two: one is Windows operating system, the other is Linux operating system. Although the latter is free and supported a lot of applications. The shortage of Linux driver to obstructs the user to get equally support like Windows. It also slashes Linux popularity in general user. Since a lot of embedded devices has been developed and applied in our life. We can see a various of device includes: digital camera、printer、mobile phone be produced. These devices need the hardware provider develop device drivers to communicate with operating system. Therefore, it’s a critical point for all providers who can rapidly develop stable and multiplatform supported device driver to compete with others. Besides, if you want to develop Windows device driver, you must highly understand the hardware of the device、all function require of the device and Windows Driver Model. The above things will take programmer a lot of times to learn and not to mention develop Linux device driver. All the factors will also influence the time to market. Actually, to develop the driver between Windows and Linux, the hardware and functionality will be the same except the device driver model. Therefore, we discuses the feasibility of porting driver from Windows 2000 to Linux 2.6 and using Lex/Yacc to build an extendable mapping and transfer mechanism in different device and platform. Hope it can save the time for driver developer’s to build drivers between two platforms. Keywords: Porting、Windows 2000、Linux 2.6、Device Driver Model、Driver Generator、 Lex/Yacc. ii.

(5) 誌. 謝. 感謝張瑞川教授讓我加入計算機系統實驗室，近而有機會接觸作業系統核心知識。此外要感謝張大緯教授不辭辛勞的指導，在選題、構思、寫作及完稿過程中提醒我許多考慮欠週的地方並提供可能的解決方法。在實驗室的期間要感謝學長學弟的幫忙，尤其要感謝實驗室老大張明絜的協助；感謝彭美僑及陳彥百學弟給我 Lex/Yacc 方面的指導；感謝戴函昱學弟給我 Linux 2.6 驅動程式模型的指導；感謝邱國政學弟給我口試前的指導；感謝我的朋友謝博文、許伯鈞給予我許多論文撰寫的經驗及壓力調適的方法。研究所兩年，還要感謝惠我良多的鐘崇斌教授要求我們在學習上保有嚴謹的態度、認真的精神、自我要求及獨立思考的能力；感謝一路上一起努力學習的同學們；最後僅將此成果獻給最關心我的母親。. iii.

(6) INDEX 摘. 要 .................................................................................................................................. i. ABSTRACT .................................................................................................................................... ii 誌. 謝 ................................................................................................................................ iii. INDEX ........................................................................................................................................... iv LIST OF FIGURES..................................................................................................................... vii LIST OF TABLES....................................................................................................................... vii 1 Introduction .............................................................................................................................. 10. 2. 3. 4. 5. 1.1. Motivation and Objective ....................................................................................... 10. 1.2. Background and Relateive Research ..................................................................... 10. 1.3. Limitation of Research............................................................................................ 11. 1.4. Architecture and Content of Research .................................................................. 11. The Comparison of Device Driver Model ......................................................................... 12 2.1. The Architecture of Device Driver and HAL........................................................ 12. 2.2. Introduction the Device Driver Model .................................................................. 12. 2.3. Enumerate Device.................................................................................................... 14. 2.4. Store Driver Relative Information......................................................................... 16. 2.5. Supported Hardware List and Access Type ......................................................... 17. 2.6. The Different Between two Platforms Driver ....................................................... 18. The Comparison of Development Environment............................................................... 21 3.1. Check System Device Driver .................................................................................. 21. 3.2. Compiler Require Files ........................................................................................... 21. 3.3. Building Environment............................................................................................. 22. 3.4. Manual Install、Located and Set Loading Sequence .......................................... 23. 3.5. Debug Kernel Mode Driver .................................................................................... 24. The Classify of Driver Function ......................................................................................... 27 4.1. The Skeleton of Program Function........................................................................ 27. 4.2. Classify the Map with Driver Function ................................................................. 29. The Comparison of Driver Function ................................................................................. 32 5.1. Entry Function Point in Driver .............................................................................. 32. 5.2. Hardware.................................................................................................................. 34. 5.3. Reply Status ............................................................................................................. 35 iv.

(7) 6. 5.4. Data Type ................................................................................................................. 36. 5.5. Create Device Object and Set Permission ............................................................. 36. 5.6. I/O Control ............................................................................................................... 38. 5.7. Memory Management ............................................................................................. 39. 5.8. Interrupt ................................................................................................................... 39. 5.9. Synchronization ....................................................................................................... 40. 5.10. Double Linked List .................................................................................................. 42. 5.11. Timer ........................................................................................................................ 42. 5.12. Work Thread ........................................................................................................... 43. 5.13. Module Description and Function Export ............................................................ 43. 5.14. IRP Relative Function ............................................................................................. 43. 5.15. Others ....................................................................................................................... 44. Porting Basic Driver–Use Parallel Device......................................................................... 46 6.1. Analysis Each Function Block................................................................................ 46. 6.2. Introduce Parallel Port Device ............................................................................... 47. 6.3. Map Program Section ............................................................................................. 49. 6.4 7. 6.3.1. Map Include File.......................................................................................... 49. 6.3.2. Map Function Declaration Area ................................................................ 50. 6.3.3. Map Global Data Area ................................................................................ 50. 6.3.4. Map Driver Internal Data........................................................................... 51. 6.3.5. Map Driver Entry Function ....................................................................... 52. 6.3.6. Map Create Function Block ....................................................................... 53. 6.3.7. Map Close Function Block.......................................................................... 54. 6.3.8. Map Write Function Block ......................................................................... 54. 6.3.9. Map Ioctl Function Block ........................................................................... 55. Test............................................................................................................................ 56. Using Lex/Yacc to Build Driver Generator....................................................................... 58 7.1. Transfer Model ........................................................................................................ 58. 7.2. Full Map Function................................................................................................... 58. 7.3. Use Lex to Recognize String and Build Token ..................................................... 59. 7.4. Use Yacc to Build the Grammar Rule ................................................................... 60. 7.5. Relocate All Token .................................................................................................. 63 v.

(8) 8. Conclusion and Future Work............................................................................................. 64. 9. References ............................................................................................................................ 65. Appendix A. Windows Driver Skeleton..................................................................................... 66 Appendix B. Linux Driver Skeleton........................................................................................... 72. vi.

(9) LIST OF FIGURES Figure 1: Use HAL Routines to Access Hardware ................................................................... 12 Figure 2: Use HAL Routines to Access Hareware in Windows .............................................. 13 Figure 3: Use HAL Routines to Access Hareware in Linux .................................................... 14 Figure 4: Physical Device Object vs Function Device Object in Windows ............................ 14 Figure 5: Kset vs Kobject in Linux ............................................................................................ 15 Figure 6: Windows Device Tree ................................................................................................. 15 Figure 7: Linux Device Tree ....................................................................................................... 16 Figure 8: The Class Key between Windows and Linux ........................................................... 17 Figure 9: Check All the Devices Driver in System ................................................................... 21 Figure 10: Windows DDK has Checked and Free Build ......................................................... 23 Figure 11: Loading Sequence in Windows Driver.................................................................... 24 Figure 12: OS Crash in Both Platforms .................................................................................... 25 Figure 13: Store the Function Map in Database....................................................................... 32 Figure 14: The Comparison of Program Section...................................................................... 46 Figure 15: 25 pins Null Modem .................................................................................................. 47 Figure 16: Parallel Port Introduction........................................................................................ 48 Figure 17: Convert all Full Map Function to Lex Definition .................................................. 59. LIST OF TABLES Table 1: Tool for Driver Generator ........................................................................................... 10 Table 2: The Comparison of Driver Information in Two Platforms ...................................... 16 Table 3: The Example with Windows Hardware ID................................................................ 17 Table 4: The Example with Linux Hardware ID...................................................................... 18 Table 5: Windows and Linux's Access Type............................................................................. 18 Table 6: The Different between Windows and Linux Driver.................................................. 19 Table 7: Compiler Required Files.............................................................................................. 22 Table 8: The Example with Makefile......................................................................................... 22 Table 9: Compile your Device Driver ........................................................................................ 22 Table 10: Management and Located of Device Driver ............................................................ 23 Table 11: Driver Loading Sequence .......................................................................................... 23 Table 12: Debug Relative Function and Tool ........................................................................... 24 vii.

(10) Table 13: Construct a Program Function ................................................................................. 27 Table 14: The Category of Single Identifier.............................................................................. 28 Table 15: The Statistic of Function Map ................................................................................... 30 Table 16: Full Map with Data Copy Function.......................................................................... 30 Table 17: Partial Map with I/O Map Function......................................................................... 30 Table 18: Partial Map with Memory Set Function .................................................................. 31 Table 19: Linux Only Function .................................................................................................. 31 Table 20: Windows Only Function ............................................................................................ 31 Table 21: Driver Relative Mapping Data.................................................................................. 32 Table 22: The Entry Function between Windows and Linux ................................................. 34 Table 23: The Hardware Function between Windows and Linux.......................................... 35 Table 24: The Map of Port I/O Function .................................................................................. 35 Table 25: The Reply Status between Windows and Linux ...................................................... 36 Table 26: The Data Type between Windows and Linux.......................................................... 36 Table 27: Create Device Object and Set Driver Permission.................................................... 37 Table 28: Determine I/O Type between Windows and Linux ................................................. 37 Table 29: Create Device Function between Windows and Linux ........................................... 38 Table 30: The I/O Control between Windows and Linux........................................................ 39 Table 31: The Memory Management Function between Windows and Linux ..................... 39 Table 32: The Interrupt Function between Windows and Linux ........................................... 40 Table 33: The Interrupt Function between Windows and Linux ........................................... 40 Table 34: The Synchronization Function between Windows and Linux ............................... 42 Table 35: The Double Linked List Function between Windows and Linux .......................... 42 Table 36: The Timer Function between Windows and Linux................................................. 43 Table 37: The Work Thread Function between Windows and Linux.................................... 43 Table 38: The Module Description is Linux Only Function.................................................... 43 Table 39: The EXPORT_SYMBOL is Linux Only Function.................................................. 43 Table 40: The IRP Relative Function between Windows and Linux ..................................... 44 Table 41: The Symbolic Link Function between Windows and Linux .................................. 44 Table 42: The Break When False and Memory Barrier Function between Windows and Linux ..................................................................................................................................... 45 Table 43: Set Thread Priority between Windows and Linux.................................................. 45 viii.

(11) Table 44: Parallel Port Pins........................................................................................................ 48 Table 45: Linux Mapped Header Files...................................................................................... 49 Table 46: Linux Mapped Header Files...................................................................................... 50 Table 47: The Comparison of Program Section ....................................................................... 50 Table 48: The Comparison of I/O Control and Device Name ................................................. 51 Table 49: The Comparison of Driver Internal Data ................................................................ 52 Table 50: The Comparison of Entry Function.......................................................................... 53 Table 51: The Comparison of Create Function ........................................................................ 54 Table 52: The Comparison of Close Function .......................................................................... 54 Table 53: The Comparison of Write Function.......................................................................... 55 Table 54: The Comparison of Ioctl Function............................................................................ 56 Table 55: Use W2L.l to Build Token and Compile by Lex ...................................................... 61 Table 56: Use W2L.y to Relocate and Compile by Yacc.......................................................... 62 Table 57: Generate the y.tab.h to Define Token....................................................................... 63. ix.

(12) 1 Introduction 1.1 Motivation and Objective 把 Windows 驅動程式移植(Porting)到 Linux 平台並不是為了反微軟或者特意支持自由軟體，而是因為工作經常在撰寫這兩個平台的驅動程式，越接觸就越發覺兩者有不少共同點，也就越想了解這兩個平台的驅動程式、作業系統及裝置之間互動機制的異同，最後便興起了互轉兩個平台驅動程式的念頭，希望能幫助 Windows 平台的驅動程式設計者能更快速的開發出 Linux 平台的驅動程式。最初題目訂為：不同平台驅動程式之互換，打算著手兩邊驅動程式互換，但後來發現僅僅單一平台的驅動程式就已經非常的龐大，如果要做兩邊互轉範圍實在太大，短期間非我一己之力能夠完成，與教授討論後，教授認為市面上驅動程式普遍都有撰寫支援 Windows 平台的驅動程式，少有支援 Linux 的驅動程式，多數的裝置無法在 Linux 平台找到對應的驅動程式，也因此造成 Linux 的普及率比較低，因此建議我做移植 Windows 裝置驅動程式至 Linux 的移植，希望能研究出一套模型將 Windows 驅動程式快速地移植到 Linux 平台。. 1.2 Background and Relateive Research 各種類別的裝置在 Windows 及 Linux 均有其特有的裝置驅動程式模型(Device Driver Model)，而市面上開發驅動程式產生器(Driver Generator)相關產品的公司有 Jungo 及 Compuware 這兩家公司，但也只針對較常見的 USB、PCI 及 Network 的裝置做單一平台驅動程式產生器，並沒有兩個平台驅動程式互轉的工具，如 Table 1 所示。 Windows. Linux. VxWorks. Jungo - WinDriver. USB/PCI. USB/PCI. USB/PCI. Compuware - SoftICE. USB/PCI. --. --. Provider. OS. Table 1: Tool for Driver Generator 論文研究方面在 2004 年南非大學曾在 acm 提出這兩種平台的一般用途驅動程式 (General Purpose Driver)做簡略的比較[2]，但其它像記憶體管理、計時器(Timer)、同步 (Synchronous)、中斷(Interrupt)、執行緒(Thread)、硬體及工作佇列等部分並沒有做任何的探討。而對岸的論文則有探討 Windows 或 Linux 單一平台下的驅動程式做程式自動產生器的研究，國內則有長庚大學馮立琪教授及暨南大學姜美玲教授提出裝置驅動程式模型(Device Driver Model)相關論文之探討。在研究的期間也發現將 Windows 平台的應用程式移植(Porting)到 Linux 平台，將 MFC 的 GUI 程式轉換成 gtk+的程式的工具－wxWindows[1][3]，雖然轉換的程式類型不同，但也提供一個可參考的轉換模型。. -10-.

(13) 1.3 Limitation of Research 由於兩個平台關於驅動程式相關函數眾多，本研究參考 DDK 網站統計常用的 Windows 函數來對映(Mapping)到 Linux 平台。且兩個平台驅動程式大多使用 C 語言開發，因此本研究僅限於 C 語言開發的 Driver Code 做移植，C++則不予以討論。此外，Windows 及 Linux 均將 Driver 區分為 Kernel Mode Driver 及 User Mode Driver[17][18]，本研究僅就 Kernel Mode Driver 做探討。並以 Windows 2000[10][11][14][15][22]移轉到 Linux 2.6[4][6][9][12][13][16]做主要探討之平台，在轉換程式只限制處理已編譯正確的 Windows Driver Code。主要研究以兩個平台裝置驅動程式模型(Device Driver Model)及一般用途的字元驅動程式(General Purpose Character Driver)作轉換，並以 Parallel Port Driver[7]為例來轉換及測試；至於兩個平台編譯連結的 makefile 及 Windows INF 檔並不做轉換程式。. 1.4 Architecture and Content of Research 對照的方法將由小至大比對：從單一識別字(Single Identifier)的對應Æ到整句函式原型(Function Prototype)的對應Æ再到整個函式區塊(Function Block)的對應Æ最後再到整個程式區段(Program Section)的對應。轉換的方法則是使用 MS-SQL Server 為資料庫，建立 DDK 常用函數的對應及分類，再用 Lex/Yacc 建立轉換所需的權杖及文法規則(Token/Grammar Rule)檔，最後再讀取 Windows Driver 的 Token 重新定位(Relocate)到 Linux Driver 的對應格式，如此便可完成整個函式區塊對應(Function Block)。論文內容則分為九章，主要敍述如下: 一、緒論：簡要概述整個論文的研究目的、研究範圍及研究架構。二、裝置驅動程式模型(Device Driver Model)比較。三、開發及編譯環境之比較。四、兩個平台上裝置驅動程式架構的比較。五、兩個平台上裝置驅動程式函數比較：包括記憶體管理、計時器、同步、中斷、硬體、資料型式及工作佇列之比較六、驅動程式的轉換-以 Parallel Device 為例。七、以 Lex 及 Yacc 來建立驅動程式之程式產生器。八、結論及未來方向。九、參考文獻。. -11-.

(14) 2 The Comparison of Device Driver Model 2.1 The Architecture of Device Driver and HAL Windows 實作了一個 hal.dll(/winnt/systen32/hal.dll)來提供與硬體無關的介面給上層，讓上層透過硬體抽象層(HAL，Hardware Abstract Layer)與硬體溝通，而無須考慮硬體的差異，與硬體平台有關的部分均透過 hal.dll 來負責處理。 Linux的硬體抽象層在其核心原始程式碼(/lib/modules/version/kernel/)的/arch目錄 [9]，此目錄包含所有支援的處理器，如下面指令所示： [root@hlchou /hal/linux/arch]# ls alpha/ cris/ ia64/ mips/ parisc/ s390/ sh/ sparc64/ arm/ i386/ m68k/ mips64/ ppc/ s390x/ sparc/ 透過這些與硬體相關的基本函式配合上層運作的其它模組，便可以在最小修改的情況下完成與硬體抽離的架構。如 Figure 1 所示[5]： Windows. Linux. Figure 1: Use HAL Routines to Access Hardware. 2.2 Introduction the Device Driver Model Windows將Driver分成三類，分別為Bus Driver、Filter Driver及Function Driver，而 Driver所產生的Device Object分別有Physical Device Object(PDO)、Function Device Object(FDO)及Filter Device Object(FiDO)。Windows其Bus Driver與Function Driver的關係為Parent/Child Relationship，當開始放入硬體時，扮演Parant的Bus Driver用來列舉 -12-.

(15) (Enumerate)出匯流排上裝置的Hardware IDs並產生PDO，隨後系統載入對應的Child Function Driver來管理該Device，而Filter Driver則有過濾、觀察及修改封包的功能，可被放置在Function Driver的上下層。 Microsoft在Windows 2000/98/ME之後版本的Driver開始遵從Windows Driver Model(WDM)，WDM的Driver支援隨插即用(Plug and Play)、電源管理(Power Management) 及Windows Management Instrumentation (WMI)。由OS的隨插即用管理員(Pnp Manager)、 I/O管理員及電源管理員(Power Manager)來控管Device的生命週期，此外Windows Driver 使用IRP(I/O Request Packet)來傳遞資訊1，即使負責的Driver不必使用到IRP的資料，也要將IRPs傳遞給其它層的Driver，如Figure 2[2]所示。. Figure 2: Use HAL Routines to Access Hareware in Windows Linux在Kernel 2.6版也加入隨插即用(Plug and Play)、電源管理(Power Management) 及熱插拔(hotplug)的機制。Linux為了實作電源管理，因此在2.6版加入了KSet及Kobject 來定義Bus Driver與Child Driver之間上下層的關係，以便讓各個Device在電源關閉時有正確先後的順序，如Figure 3[2]所示。 1. 除了一些特殊的 Driver 不處理 IRP，比如 NDIS miniport driver 是呼叫 NDIS 所的函數來註冊. -13-.

(16) Figure 3: Use HAL Routines to Access Hareware in Linux. 2.3 Enumerate Device Windows的Bus Driver會產生出一個個的Device Object並串接起來，如Figure 4所示。首先Bus Driver產生本身的FDO，接下來再產生Child PDO，利用每個新產生的Device Object其NextDevice欄位來串接各個Child Device Object，所有的Device Object均指向同一個Driver Object，並用ReferenceCount來計數這個物件被參照的次數[22]。 typedef struct _DEVICE_OBJECT { CSHORT Type; USHORT Size; LONG ReferenceCount; struct _DRIVER_OBJECT *DriverObject; struct _DEVICE_OBJECT *NextDevice; union { LIST_ENTRY ListEntry; WAIT_CONTEXT_BLOCK Wcb; } Queue; …. }. Figure 4: Physical Device Object vs Function Device Object in Windows. -14-.

(17) 在Linux也有雷同的機制，每個kobject均指向同一個kset，每個kobject再彼此串接成 kset child list，並同時有ReferenceCount來得知物件被引用的次數，如Figure 5[4]。 struct kobject { char * k_name; char name[KOBJ_NAME_LEN]; struct kref kref; struct list_head entry; struct kset * kset; struct kobject * parent; struct kobj_type * ktype; struct dentry * dentry; }; Figure 5: Kset vs Kobject in Linux 接下來再用Bus Driver列舉(Enumerate)下去就會形成一個Device Tree，如Figure 6及 Figure 7分別為Windows Device Tree及Linux Device Tree。Windows藉由PnP Manager來維持整個Device Tree的架構，而Linux則使用probe/remove/match/hotplug等函數來維持其 Device Tree。. Figure 6: Windows Device Tree. -15-.

(18) Figure 7: Linux Device Tree. 2.4 Store Driver Relative Information Windows平台將Device、Driver與Bus的關聯及一些設定的資訊儲存在Registry(可以在StartÆRun，輸入regedit來查看內容)，而Linux在核心2.6版也開始有相對應的資訊，這些資訊被放在sysfs2裏，sysfs是一個存在記憶體的Virtual File System，可用來建構完整的 Device Tree，在命令列使用tree command可查看其內容(#tree /sys)。由Table 2可看到 Windows的Registry與Linux的sysfs所對應的Hardware Key、Service Key及Class Key。 OS. Windows Registry. Linux sysfs. HKLM\System\CurrentControlSet\Enum. /sys/devices. Key Hardware Key (represents all of the devices). Service Key HKLM\System\CurrentControlSet\Service (represents the device Drivers). /sys/bus/drivers. Class Key (represent the class). /sys/class. HKLM\System\CurrentControlSet\Control\Class. Table 2: The Comparison of Driver Information in Two Platforms Figure 8可看兩種OS均有Class Key，用來存放Device抽象化後的類別，如網路卡可以是PCI、USB、PCMCIA的介面，但都屬於Network Class。 2. Linux 2.6 建議程式設計師將控管 Driver 的資訊由以往的/proc 目錄移至/sys 目錄. -16-.

(19) Windows. Linux # tree /sys/class |-- bluetooth |-- firmware | `-- timeout |-- graphics |-- i2c-adapter |-- i2c-dev |-- input | |-- event0 | | `-- dev | |-- event1 | | `-- dev | |-- mice | | `-- dev | `-- mouse0 | `-- dev |-- net | |-- eth0 | | |-- addr_len | | |-- address | | |-- broadcast | | |-- device -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:06.0 | | |-- driver -> ../../../bus/pci/drivers/r8169. Figure 8: The Class Key between Windows and Linux. 2.5 Supported Hardware List and Access Type Device通常會有一塊EPROM來儲存Hardware ID，當系統偵測到硬體時，該類別的 Bus Driver會與該類別的Driver所設的ID值比對後，進而載入對應的Driver。Windows Driver將這些資訊放在*.inf檔，如Table 3，而Linux則是放在各個*_ids.h的檔案裏，像是 pci_ids.h，如Table 4。 [Manufacturer] %MfgName%=Avance. [Avance] %ALCAUD.Desc%=AC97AUD,PCI\VEN_8086&DEV_24C5&SUBSYS_000817C0 %ALCAUD.Desc%=AC97AUD,PCI\VEN_8086&DEV_24C5&SUBSYS_0241A0A0 %ALCAUD.Desc%=AC97AUD,PCI\VEN_8086&DEV_24C5&SUBSYS_0242A0A0 %ALCAUD.Desc%=AC97AUD,PCI\VEN_1039&DEV_7012&SUBSYS_0247A0A0 %ALCAUD.Desc%=AC97AUD,PCI\VEN_1039&DEV_7012&SUBSYS_0248A0A0. Table 3: The Example with Windows Hardware ID. -17-.

(20) static struct pci_device_id i810_ids[] __devinitdata = { { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82810_IG1) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82810_IG3) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82810E_IG) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82815_CGC) }, { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82845G_IG) }, { 0, }, };. Table 4: The Example with Linux Hardware ID Windows Driver存取資料的方式有兩種，分別為Buffer I/O與Direct I/O；Buffer I/O 為預設值，用在資料量小、傳輸速度較慢的Device，如滑鼠及鍵盤；而Direct I/O則用在資料量大、需要快速傳輸的Device，像PIO或DMA的傳輸方式，常見的Device有SCSI Disk 及VGA Card。在Linux也依存取方式將Driver分成兩種，一為處理少量資料的Character Device Driver，另一種則是以Block的單位來存取資料的Block Device Driver，如Table 5[22]。 Windows Buffer I/O. Direct I/O. Linux Character Device Driver Block Device Driver. Characteristic Slow/small size，but it’s. Device Mouse、Keyboard. default and easy to use/nonpage pool Fast/large size，but hard to. SCSI Disk、VGA. use. (PIO or DMA). Card. Table 5: Windows and Linux's Access Type. 2.6 The Different Between two Platforms Driver 兩個平台其Device Driver各有其特有做法及部分的差異，如Table 6，本節就其差異做討論。 Windows Only. Linux Only. IRP. GPL/non GPL. Filter driver. likely function to optimistic compiler. WMI. Use set bit & test bit. Unicode IRQL Function can be pagable/non-pagable Similar Issue Symbolic link to access by application. Symbolic link to link with sysfs -18-.

(21) Major/Minor function. Major/Minor device. Pass Parameter Using INF File. Pass Parameter Using insmod Command. Put a lot information in INF file. Put in driver code. Table 6: The Different between Windows and Linux Driver z Windows Only，也就是Windows存在但Linux不存在的部分：－ Windows把某些資訊集合起來，放在一個特定的IRP(I/O request packet)Structure 裏，因此各個Entry Function都使用IRP變數來傳遞，Linux沒有這樣統一的封包格式，因此每個Entry Function所傳入的變數都不一樣。－因Windows Driver不像Linux為開放原始碼，因此無法看到Source Code，一般使用者無法自行修改/重新編譯Driver，所以微軟創造了Upper及Lower Filter Driver，能有彈性的掛在Function Driver上下層去觀察及修改Packet的資料，而Linux就可以直接改Driver Code，因此少有這層動作。－ Windows有Windows Management Instrumentation(WMI)的設定的機制，可向系統管理員報告管理訊息及允許用戶設定控制設備的操作，Linux則沒有。－ Windows所有字串都要轉成Unicode的資料型別才能與使用者應用程式溝通， Linux則沒有這樣的資料型別要轉換。－ Windows Driver的各個函數均有指定其IRQ層級(Interrupt Request Level)，限制各個函數要在某個層級才能執行，以整增加整個Driver的執行速度，Linux則沒有。－ Windows有限制某些Function一定要使用不可分頁的分頁區(Nonpagable Page)，強制該行程在整個Driver執行期間不可被置換空間(Swap Out)到記憶體外，在 Linux之下沒有規定，如下所示，函數IsoUsb_DispatchCreate被指定要放在可分頁區： #pragma alloc_text(PAGE, IsoUsb_DispatchCreate) z Linux Only，也就是Linux存在但Windows不存在的部分：－ Linux有unlikely函數來加強編譯時最佳化的處理，Windows則沒有。－因Linux為Open Souce的平台，因此其Linux Module有區分GPL及non GPL，如果您將Driver設為non-GPL則會因此無法使用GPL only的Symbols。－ Linux有set bit及test_bit的位元操作(Bit Operations)，Windows則沒有。 z Similar Issue，也就是兩個平台相近的部分：－ Windows及Linux都有提到Symbolic Link，但兩邊意義不同。Windows的 Symbolic Link可以開啟一個讓Application存取的介面，而Linux則是用來建立sysfs內 Device與Driver的關聯。－ Windows及Linux都有提到major及minor number但兩邊意義不同。Window的 major及minor是指Driver Entry Function；Linux則是12 bits的major加上20 bits的minor組成一個32 bits的Unique ID，這部分類似Windows的16 bytes GUID，用來辨識一個唯一 (Unique)的Device。 -19-.

(22) － Linux在插入模組(insmod)時，可帶入參數，在Windows則是在INF檔帶入參數。－ Windows 有許多 Driver 資訊被放在 INF 檔，而 Linux 則是放在程式內，如 Class、 Hardware ID、Input Parameter、Device Description、Device Display Name，因此這部分也需撰寫轉換到 Linux 對應的程式。. -20-.

(23) 3 The Comparison of Development Environment 在開始比對兩邊Device Driver的程式碼前，想先就整個作業系統在驅動程式的安裝及編譯及開發環境做粗略的對應及比較，進而了解Device Driver在兩個平台開發環境的異同及Driver運作機制。. 3.1 Check System Device Driver 在Windows要查看所有已載入的Device Driver要開啟Device Manager （StartÆRun，輸入devmgmt.msc)，在Linux則使用lsmod指令來查看核心目前載入那些 Driver Modules，如Figure 9所示。 Windows’s Device Manager. Linux’s lsmod command. Figure 9: Check All the Devices Driver in System. 3.2 Compiler Require Files 一般來說，要能在 Windows 平台成功編譯一個基本的驅動程式需要四類檔：第一個是 makefile 檔第二個是 Driver Source Code 第三個是 sources 文件第四個檔是 RC 檔 -21-.

(24) RC 檔及 sources 檔是根據需求修改。Linux 平台只需 makefile 及 Driver Code 即可，如 Table 7 所示。 Windows. Linux. makefile *.c、*.h. makefile *.c、*.h. RC sources Table 7: Compiler Required Files 兩邊的編譯檔都有使用Makefile，Makefile是用來指定要編譯的檔及要連結的函式庫(Library)。不過Windows不用修改Makefile，而是用sources檔來取代Makefile的功能。 Table 1是兩邊編譯程式的範例，作法十分類似，但本論文將不會探討兩個平台Makefile 的轉換。 source in Windows makefile in Linux obj-m := TestDriver.o TARGETNAME = TestDriver TARGETPATH = obj KDIR := /lib/modules/$(shell uname TARGETTYPE = DRIVER -r)/build MSC_WARNING_LEVEL =/W3 PWD := $(shell pwd) C_DEFINES = $(C_DEFINES) EXTRA_CFLAGS := -I/usr/test/include /DMAXDEBUG /DDEBUG /DDBG=1 -I/usr/include/ SOURCES = TestDriver.c PRECOMPILED_INCLUDE=precomp.h PRECOMPILED_PCH =precomp.pch default: $(MAKE) -C $(KDIR) PRECOMPILED_OBJ=precomp.obj SUBDIRS=$(PWD) modules Table 8: The Example with Makefile. 3.3 Building Environment 在Windows平台編譯Driver必須安裝Windows DDK(Device Driver Kit)，用其編譯器來編譯Device Driver，而Linux則是使用一般的gcc(GNU Compiler Collection)來編譯程式。其編譯指令如Table 9。 Windows use DDK Building tools Linux use gcc C:\WINDDK\3790\src\network\ndis\netvm #gcc -D__KERNEL__ -DMODULE ini>build -cZ -I/usr/src/linux-2.6.10/include -c -O -Wall demodriver.c -o demodriver.ko #./makefile Table 9: Compile your Device Driver 如Figure 10，Windows Device Driver的編譯與連結是由DDK Builder來控制，其編譯器有Checked與Free兩種版本[22]。Checked Build建立含有除錯資訊的驅動程式，您可 -22-.

(25) 在開發時期使用。編譯程式最佳化在此狀況下是停用的狀態且程式中將會加入用於 Debugging的條件程式碼。Free Build則是用於要發行的驅動程式，此時程式碼已經過最佳化且Debug程式碼已被停用。在此環境下編譯完成的驅動程式您可用於效能測試或寄送給客戶，對應到Linux相當於在gcc編譯時使用參數-O來做最佳化，如Table 9右方Linux 的部分所示。. Figure 10: Windows DDK has Checked and Free Build. 3.4 Manual Install、Located and Set Loading Sequence 在Windows平台手動安裝Driver須使用Device Manager來幫忙安裝，而在Linux則是用insmod及remod指令安裝及移除；Driver放置的位置及副檔名分別整理在Table 10。 Windows Linux OS Odds The way to manual install The way to manual remove Driver configuration file Driver location. Create an INF file and use Device Manager to install Remove the device driver by Device Manager %win%/inf. Driver file extension. *.sys. %win%/system32/drivers. # insmod ./fdo.ko # rmmod ./fdo.ko /etc/modules.conf(#modprobe) /lib/modules、/proc/modules、 /sys/modules *.ko. Table 10: Management and Located of Device Driver 若要指定Device Driver開機後的啟動順序，分別可在Windows的Registry及Linux Kernel的drivers目錄下，修改makefile，如Table 11及Figure 11。 Windows Set the LoadOrderGroup in INF File to set the boot sequence in HKLM\CurrentControlSet\Control\ServiceGroupOrderKey Linux usr\src\linux-2.6.9\drivers\Makefile Table 11: Driver Loading Sequence. -23-.

(26) Figure 11: Loading Sequence in Windows Driver. 3.5 Debug Kernel Mode Driver 兩邊的平台也各提供了一些類似的方法讓我們在Kernel Mode有和善的除錯工具， Table 12為兩個平台相關的函數及工具。 Windows Linux OS Odds Print message function. KdPrint();. printk();. False then break expression. ASSERT();. BUG_ON(); WARN_ON();. Show the message. DbgViewer Tool. #dmesg message can appear at console and /var/log/messages. Kernel mode debugging tools Document. WinDbg/KD/SoftICE/Dump Kernel Memory DDK. gdb/Oops usr/src/linux/Documentation/. Table 12: Debug Relative Function and Tool 在撰寫驅動程式的過程中有時會導致整個系統當機，在Windows平台會顯示藍色死. -24-.

(27) 亡畫面("Blue Screen of Death" - BSOD)，並秀出錯誤的位址及錯誤代碼(Bug Code)3，而 Linux也有類似的訊息來告知使用者系統已當機，如Figure 12。 Windows example blue screen. Linux will show panic or halt. Figure 12: OS Crash in Both Platforms 3. 相關資料請查看 DDK 的 inc\w2k\bugcodes.h. -25-.

(28) 從上面的種種對應及比較可以看出兩個平台在編輯及處理程式提供了許多功能相近的工具，也因此我們可用這些工具觀察出兩個平台驅動程式與作業系統、硬體互動的更多對應之處。. -26-.

(29) 4 The Classify of Driver Function 4.1 The Skeleton of Program Function 要分析及轉換一個程式前，我們必須先了解一個程式的結構，以下面一個C語言所寫的範例為例： void main() { printf(“ 5 + 5 = ＂, add(5,5)); } int add(x,y) { return sum(5,5); } 程式由小到大的分別由三個步驟完成，如Table 13紅色箭頭所示： Step 1：單一識別子( Single Identifier)組成一行函數原型(Function Prototype)。 Step 2：每個單行的函數原型再組成一個函數區塊(Function Block)。 Step 3：所有函數區塊的集合就形成了最後的程式區段(Program Section)。 Element Single Identifier. Example void、main、int、printf、sum 、return printf(“ 5 + 5. Function Prototype. Function Block. Program Section. = ＂, add(5,5)); 、. sum(5,5); int add(x,y) { return sum(5,5); } void main() { printf(“ 5 + 5. = ＂, add(5,5));. } int add(x,y) { return sum(5,5); } Table 13: Construct a Program Function. -27-.

(30) 把要比對的識別子(Identifier)分成五種型態，存在資料庫並給予一個代號(flag)來區別，如Table 14所示，藍色字體為Windows Identifier、紅色字體為Linux Identifier，分別介紹如下： No. Flag. Type. Example. 1. F. Function. ExFreePoolÆkfree KeSetPriorityThreadÆset_user_nice. 2. S. Status. STATUS_UNSUCCESSFULÆ-EFAULT STATUS_DEVICE_BUSYÆ-EBUSY. 3. P. Function Parameter. PagedPoolÆGFP_KERNEL NonPagedPoolÆGFP_ATOMIC. 4. T. Data Type. PUINTÆunsigned int * KSPIN_LOCK Æspinlock_t LIST_ENTRYÆlist_head. 5. D. Driver Only. DriverEntryÆfile_operations DEVICE_EXTENSIONÆprivate_data. Table 14: The Category of Single Identifier z. 第一種F為函數，釋放記憶體的函數原型在Windows和Linux分別為：. VOID ExFreePool(IN PVOID P); void kfree (void *ptr); 以及調整執行緒優先權的函數原型在Windows和Linux分別為： KPRIORITY KeSetPriorityThread(IN PKTHREAD Thread, IN KPRIORITY Priority); void set_user_nice ( task_t *p , long nice); 以及插入項目到串列尾部的函數原型在Windows和Linux分別為： VOID InsertTailList(IN PLIST_ENTRY void list_add_tail(struct list_head *new, z. ListHead,IN PLIST_ENTRY Entry); struct list_head *head);. 第二種S為回傳的狀態值，失敗的回傳值在Windows和Linux分別為：. STATUS_UNSUCCESSFUL -EFAULT 以及裝置忙碌的回傳值在Windows和Linux分別為： STATUS_DEVICE_BUSY -EBUSY. -28-.

(31) z. 第三種P為函數的參數值，可移出分頁的參數在Windows和Linux分別為：. PagedPool GFP_KERNEL 以及不可移出分頁的參數在Windows和Linux分別為： NonPagedPool GFP_ATOMIC z. 第四種T為資料型態，指向無正負符號的整數型態變數，在Windows和Linux 分別為：. PUINT unsigned int * 以及自旋鎖的資料型別在Windows和Linux分別為： KSPIN_LOCK spinlock_t 以及雙向鏈結串列型態在Windows和Linux分別為： LIST_ENTRY list_head z. 第五種D為驅動程式特有的識別子，驅動程式指定Entry Function在Windows和 Linux分別為：. DriverEntry file_operations 以及驅動程式內部資料在Windows和Linux分別為： DEVICE_EXTENSION private_data. 4.2 Classify the Map with Driver Function 收集常用的Function比對後，可以完全對應(Full Map)的Identifier有77個，部分對應 (Partial Map)的有33個，只有Windows才有的Function有73個，只有Linux才有的Function 有28個，如Table 15。 Symbol Map. Count. 0. Full Map. 77. 1. Partial Map. 33. 2. Only for Windows, will mark it. 73. 3. Only for Linux, no influence or added. 28. -29-.

(32) Total 211 Table 15: The Statistic of Function Map 兩邊的程式都是使用C語言來撰寫，所以平時用到的函數，如sizeof()、sum()函數在兩個平台的寫法是一樣的，因此不須修改及轉換。 z. Full Map：是指函數功能相同及參數相同者。以資料複製的函數為例，如Table 16，在Windows的函數名為RtlCopyMemory，在Linux函數名為 copy_from_user，均有指定來源、目的及長度參數，則可直接將函數名做置換即可。 Windows. Function. VOID. Prototype. Token without. Linux RtlCopyMemory(. Unsigned long copy_from_user(. IN VOID UNALIGNED *Destination,. void *to,. IN CONST VOID UNALIGNED *Source,. const void *from,. IN SIZE_T. unsigned long n. Length. );. );. RtlCopyMemory. copy_from_user. parameter. Table 16: Full Map with Data Copy Function z. Partial Map：函數功能完全相同但參數部分相同，以I/O位址對映到記憶體的函數為例，如Table 17，在Windows的函數名為MmMapIoSpace，在Linux函數名為ioremap，均有指定記憶體位置及大小的參數，但Windows平台多了一個指定CacheType的參數。. Function Prototype. Windows. Linux. PVOID MmMapIoSpace(IN. void *ioremap(. PHYSICAL_ADDRESS PhysicalAddress,. unsigned long phys_addr,. IN ULONG NumberOfBytes,. unsigned long size. IN MEMORY_CACHING_TYPE CacheType. );. ); Token with. MmMapIoSpace. ioremap. parameter. Table 17: Partial Map with I/O Map Function 另一個類似的例子是將某塊記憶體清空為零的函數，如Table 18，在Windows的函數名為RtlZeroMemory對應到Linux的函數名為memset，均有指定記憶體位置及長度的參數，但Linux平台的函數較有彈性，在第二個參數可設定將記憶體清成偏好的值。此部 -30-.

(33) 分要轉換必須將各個Identifier轉成Lex/Yacc可辨識的Token，再重新排放。 Function Prototype. Windows. Linux. VOID RtlZeroMemory(. void *memset(. IN VOID UNALIGNED *Destination,. void *s,. IN SIZE_T Length. int c, // can set to prefer value. );. size_t n );. Table 18: Partial Map with Memory Set Function z. 特殊情況一：Windows沒有但Linux才有的函數，像module_init及module_exit 這兩個函數是Linux Driver特有的函數，如Table 19。此部分轉換後由Driver Generator另行加入程式碼即可。. Map Type Include. Windows. Linux. 2F. linux/init.h Windows not Exist but Linux Exist. module_init(XXX_init);. 2F. linux/init.h Windows not Exist but Linux Exist. module_exit(XXX_exit);. Table 19: Linux Only Function z. 特殊情況二：Windows有但Linux沒有的函數，像IoCreateSymbolicLink及 IoDeleteSymbolicLink這兩個函數是Windows Driver特有的函數，如Table 20。此部分轉換到Linux後必須將Windows程式註解掉。. Map Type Include. Windows. Linux. 3F. IoCreateSymbolicLink. Windows Exist but Linux not Exist. 3F. IoDeleteSymbolicLink. Windows Exist but Linux not Exist. Table 20: Windows Only Function 有了上面的分類基礎及處理方式才能著手建立轉換模式，在後面的章節我們會使用 Lex/Yacc[19][20]來做轉換，並將這些函數的對應建立在資料庫裏以便做前置處理。. -31-.

(34) 5 The Comparison of Driver Function 有了函數分類的方法，便可著手收集Device Driver的相關函數，分類並記錄對應函數的各種屬性(Map Type)，以便轉換時能有足夠的訊息判斷及處理。在本章我們把 Windows Driver一般用途(General Purpose)的函數分成十五類並找出Linux對應的函數來探討。最後的結果會存放在資料庫，並以欄位記錄對應函數的類別、是否完全對應、Linux 函數的標頭檔以及對應的函數名稱，如Figure 13。. Figure 13: Store the Function Map in Database. 5.1 Entry Function Point in Driver Windows 將Driver所需的Entry Function利用DriverObject的變數來傳遞而Linux則是用file物件，如Table 21所示，Windows的Entry Function被註冊在 DriverObject->MajorFunction，而Linux則是註冊在file->file_operations。此外Windows將 Driver Internal Data記錄在DeviceObject->DeviceExtension而Linux則是記錄在 file->private_data。 Windows. Linux. Entry Function. DriverObject->MajorFunction. file->file_operations. Driver Internal Data. DeviceObject->DeviceExtension;. file->private_data;. Parameter will passed in. DeviceObject、IRP. file、inode, etc.. Entry Function. Table 21: Driver Relative Mapping Data -32-.

(35) Windows及Linux在Kernel Mode Driver都定義一組的基本的函數，當Driver初始化時就會註冊並呼叫這些函數，如Figure 22，一般來說整個Driver在載入及卸載的過程中會與OS有Load、Unload、Read、Write、I/O、電源、熱插拔的問題要處理。 Entry. Windows. Linux. DriverEntry(). file_operations. DriverObject->DriverExtension->AddDevice. XXX_init. Function Init. module_init(XXX_init); Unload. DriverObject->DriverUnload. XXX_exit module_init(XXX_exit);. Function. IRP_MJ_CREATE. open. pointer. IRP_MJ_CLOSE. release read4. IRP_MJ_READ IRP_MJ_WRITE. write. IRP_MJ_DEVICE_CONTROL. ioctl. IRP_MJ_FLUSH_BUFFERS. flush. IRP_MJ_SHUTDONW. module_exit(XXX_exit);. IRP_MJ_PNP Minor Functions：. Bus Driver:. IRP_MN_START_DEVICE. .match. IRP_MN_QUERY_STOP_DEVICE. .hotplug. IRP_MN_STOP_DEVICE IRP_MN_CANCEL_STOP_DEVICE. Child Driver:. IRP_MN_QUERY_REMOVE_DEVICE. .probe. IRP_MN_REMOVE_DEVICE. .remove. IRP_MN_CANCEL_REMOVE_DEVICE IRP_MN_SURPRISE_REMOVAL IRP_MN_QUERY_CAPABILITIES IRP_MN_QUERY_PNP_DEVICE_STATE IRP_MN_DEVICE_USAGE_NOTIFICATION 4. 因 Windows Driver 的 I/O 為非同步 I/O(asynchronous I/O)所以在 linux 的 file_operations 應選用. aio_write/aio_read 來對應，並在標頭檔加入<linux/aio.h>。. -33-.

(36) IRP_MJ_POWER Minor Functions：. Child Driver:. IRP_MN_SET_POWER. .shutdown //power off. IRP_MN_QUERY_POWER. .suspend //low power. IRP_MN_WAIT_WAKE. .resume //full power. IRP_MN_POWER_SEQUENCE. in <linux/device.h>. enum { SUSPEND_NOTIFY, SUSPEND_SAVE_STATE, SUSPEND_DISABLE, SUSPEND_POWER_DOWN, }; enum { RESUME_POWER_ON, RESUME_RESTORE_STATE, RESUME_ENABLE, };. IRP_MJ_INTERNAL_DEVICE_CONTROL. Windows Exist but Linux not Exist. IRP_MJ_CLEANUP. Windows Exist but Linux not Exist. IRP_MJ_QUERY_INFORMATION. Windows Exist but Linux not Exist. IRP_MJ_SET_INFORMATION. Windows Exist but Linux not Exist. IRP_MJ_SYSTEM_CONTROL. Windows Exist but Linux not Exist. Windows not Exist but Linux Exist. mmap. Windows not Exist but Linux Exist. check_flags. Windows not Exist but Linux Exist. llseek. Windows not Exist but Linux Exist. send_file. Table 22: The Entry Function between Windows and Linux. 5.2 Hardware Windows與Linux硬體操作的函數，如Table 23所示，大部分的函數參數相同且完全對應(Map=0)。 Map. Type Include. Windows. Linux. 0. F. asm/io.h. WRITE_PORT_BUFFER_UCHAR. outsb. 0. F. asm/io.h. WRITE_PORT_BUFFER_ULONG. outsl. 0. F. asm/io.h. WRITE_PORT_BUFFER_USHORT. outsw. 1. F. asm/io.h. WRITE_PORT_UCHAR. outb. 1. F. asm/io.h. WRITE_PORT_ULONG. outl. 1. F. asm/io.h. WRITE_PORT_USHORT. outw. -34-.

(37) 0. F. asm/io.h. WRITE_REGISTER_BUFFER_UCHAR iowrite8_rep. 0. F. asm/io.h. WRITE_REGISTER_BUFFER_ULONG iowrite32_rep. 0. F. asm/io.h. WRITE_REGISTER_BUFFER_USHORT iowrite16_rep. 0. F. asm/io.h. WRITE_REGISTER_UCHAR. iowrite8. 0. F. asm/io.h. WRITE_REGISTER_ULONG. iowrite32. 0. F. asm/io.h. WRITE_REGISTER_USHORT. iowrite16. 0. F. asm/io.h. READ_PORT_BUFFER_UCHAR. insb. 0. F. asm/io.h. READ_PORT_BUFFER_ULONG. insl. 0. F. asm/io.h. READ_PORT_BUFFER_USHORT. insw. 0. F. asm/io.h. READ_PORT_UCHAR. inb. 0. F. asm/io.h. READ_PORT_ULONG. inl. 0. F. asm/io.h. READ_PORT_USHORT. inw. 0. F. asm/io.h. READ_REGISTER_BUFFER_UCHAR. ioread8_rep. 0. F. asm/io.h. READ_REGISTER_BUFFER_ULONG. ioread32_rep. 0. F. asm/io.h. READ_REGISTER_BUFFER_USHORT ioread16_rep. 0. F. asm/io.h. READ_REGISTER_UCHAR. ioread8. 0. F. asm/io.h. READ_REGISTER_ULONG. ioread32. 0. F. asm/io.h. READ_REGISTER_USHORT. ioread16. Table 23: The Hardware Function between Windows and Linux 以Table 24所對應的函數為例，WRITE_PORT_BUFFER_UCHARÆ outsb傳入的參數都是一樣。 Function Prototype. Token without. Windows. Linux. VOID WRITE_PORT_BUFFER_UCHAR(. void outsb(. IN PUCHAR Port,. int port,. IN PUCHAR Buffer,. void *addr,. IN ULONG Count);. unsigned long count);. WRITE_PORT_BUFFER_UCHAR. outsb. parameter. Table 24: The Map of Port I/O Function. 5.3 Reply Status Windows與Linux的回傳值狀態的對應，如Table 25所示。Windows的狀態值被定義在DDK的ntstatus.h，此檔定義了500多個值；而Linux則被定義在errno-base.h，只有定義 34個值。因此無法對應的部分會先行轉成-EFALUT值，再由程式設計師自行判斷調整。 Map. Type Include. Windows. Linux. -35-.

(38) 0. S. linux/errno-base.h STATUS_INSUFFICIENT_RESOURCES -ENOMEM. 0. S. linux/errno-base.h STATUS_INVALID_PARAMETER. -EINVAL. 0. S. linux/errno-base.h STATUS_UNSUCCESSFUL. -EFAULT. 0. S. linux/errno-base.h STATUS_DEVICE_BUSY. -EBUSY. 0. S. linux/errno-base.h STATUS_UNEXPECTED_IO_ERROR. -EIO. 0. S. STATUS_SUCCESS. 0. Table 25: The Reply Status between Windows and Linux. 5.4 Data Type Windows與Linux一般資料型態的函數，兩邊函數原型(Function Prototype)幾乎完全對應(Map=0)，如Table 26所示。 Map. Type Include. Windows. Linux. 0. T. linux/types.h. PUINT. u8 *. 0. T. linux/types.h. PUSHORT. u16 *. 0. T. linux/types.h. PULONG. u32 *. 0. T. linux/types.h. PULONGLONG. u64 *. 0. T. linux/types.h. PVOID. void *. 0. T. linux/types.h. PUCHAR. unsigned char *. 0. T. linux/types.h. PUINT. unsigned int *. 0. T. linux/types.h. PUSHORT. unsigned short *. 0. T. linux/types.h. PULONG. unsigned long *. 0. T. linux/types.h. UCHAR. unsigned char. 0. T. linux/types.h. UCHAR_PTR. unsigned char *. 0. T. linux/types.h. UINT. unsigned int. 0. T. linux/types.h. UINT_PTR. unsigned int *. 0. T. linux/types.h. USHORT. unsigned short. 0. T. linux/types.h. USHORT_PTR. unsigned short *. 0. T. linux/types.h. ULONG. unsigned long. 0. T. linux/types.h. ULONG_PTR. unsigned long *. Table 26: The Data Type between Windows and Linux. 5.5 Create Device Object and Set Permission 如Table 27所示，Windows使用IoCreateDevice函數來建立DeviceObject(裝置物件)，並以DeviceCharacteristics參數設定存取權限；而Linux則是使用mknod來建立一個Device File，再使用chmod指令來設定權限，。兩者的差別在於Windows將權限寫在程式裏，而 Linux是利用指令去變更存取Device File的權限。 Windows. Linux. -36-.

(39) Format. Create device file： mknod device_file_name type major minor. NTSTATUS IoCreateDevice( IN PDRIVER_OBJECT DriverObject, IN ULONG DeviceExtensionSize, IN PUNICODE_STRING DeviceName OPTIONAL,. Change file permission： chmod permissions device_file_name. IN DEVICE_TYPE DeviceType, IN ULONG DeviceCharacteristics, IN BOOLEAN Exclusive, OUT PDEVICE_OBJECT *DeviceObject. int register_chrdev(. );. unsigned int major, const char * name, struct file_operations *fops. DeviceObject ->Flags |= DO_DIRECT_IO;. ); Driver checks any ACLs for the file name Administrator/Root Read only. Windows DeviceCharacteristics parameters. Linux chmod permissions parameters. FILE_DEVICE_SECURE_OPEN FILE_READ_ONLY_DEVICE. 700 444. Table 27: Create Device Object and Set Driver Permission Windows與Linux註冊及解註冊Device函數，如Table 28所示。Windows的 IoCreateDevice函數會根據產生的DeviceObject其Flags值(DeviceObject ->Flags)來決定對應到Linux的是register_chrdev/unregister_chrdev或register_blkdev/unregister_blkdev函數，也決定Linux用mknod命令來建立device file時要使用參數c(Character Device)或 b(Block Device)的type值(咖啡色字體)。 Map. Type Include. 1. F. linux/fs.h. 1. F. linux/fs.h. 1. F. linux/fs.h. 1. F. linux/fs.h. Windows IoCreateDevice. IoDeleteDevice. DeviceObject->Flags. Linux. DO_DIRECT_IO. register_chrdev. DO_BUFFER_IO. register_blkdev. DO_DIRECT_IO. unregister_chrdev. DO_BUFFER_IO. unregister_blkdev. Table 28: Determine I/O Type between Windows and Linux 以Table 29的例子為例，產生的裝置物件(DeviceObject)是Windows的DriverObject 對應到Linux的fops參數(紫色字體)；Windows產生裝置之相關函數為IoCreateDevice及 DeviceObject ->Flags |= DO_DIRECT_IO；對應到Linux則是register_chrdev及mknod的參數(紅色字體)；裝置名稱是Windows的DeviceName對應到Linux的name參數(深藍色字體)；裝置類別在Windows指定DeviceType為FILE_DEVICE_UNKNOWN對應到Linux為 Major5參數(咖啡色字體)；權限設定是Windows的FILE_DEVICE_SECURE_OPEN對應到 5. 在 Linux 使用 cat /proc/devices 來查看可用的 Major/Minor 值. -37-.

(40) Linux的chmod 700的permisson參數(綠色字體)。 Example. Windows char devicename=”TestDevice” status = IoCreateDevice( DriverObject, sizeof(DEVICE_EXTENSION), &DeviceName, FILE_DEVICE_UNKNOWN, FILE_DEVICE_SECURE_OPEN, 0, &fdo);. Linux # cat /proc/devices //check major # mknod /dev/TestDevice c 253 0 # chmod 700 /dev/TestDevice char name=＂TestDevice＂; int major=253; int register_chrdev( unsigned int major,. DeviceObject ->Flags |= DO_DIRECT_IO;. const char * name, struct file_operations *fops. ); Table 29: Create Device Function between Windows and Linux. 5.6 I/O Control 在32位元的平台上，Windows與Linux對於I/O Control函數6的對應也有類似的手法，如Table 30。Windows的DeviceType對應到Linux的type參數(紫色字體)，用來表示裝置類別，Windows的DeviceType共有16 bits，而Linux的type共有8 bits，如： Windows: #define FILE_DEVICE_PARALLEL_PORT 0x00000016 Linux: #define 'p' 80-9F Windows的Function Code參數對應到Linux的nr參數(綠色字體)，用來識別函數是由此裝置發出的，Windows的FunctionCode共有12 bits，而Linux的nr共有8 bits；因Windows 規定使用者自訂的I/O Control Code必須在0x8000以後，所以移轉到Linux要再減掉此數字即可。Windows的RequiredAccess參數(FILE_READ_ACCESS、 FILE_WRITE_ACCESS、FILE_ANY_ACCESS)對應到Linux的direction參數(_IOR、 _IOW、_IOWR)，均為2 bits(紅色字體)。比較不同的是Windows在Method欄位要指明存取方式是小量資料或大量資料， Linux沒有這樣的做法，因此可以忽略；但Linux尚需手動修改size參數，指定I/O Control 的資料型別。 Map. Type Include. Windows. Linux. 1. F. Windows not Exist but Linux Exist. #define _IO(type,nr). asm/ioctl.h. #define IOCTL_Device_Function 1. F. asm/ioctl.h. CTL_CODE(DeviceType, FunctionCode, Method,. #define IOCTL_Device_Function _IOR(type,nr,size). FILE_READ_ACCESS) 1. 6. F. asm/ioctl.h. #define IOCTL_Device_Function. #define IOCTL_Device_Function. CTL_CODE(DeviceType,. _IOW(type,nr,size). 請參照 Windows DDK 及 Linux Kernel 的 Documentation/ioctl-number.txt. -38-.

(41) FunctionCode, Method, FILE_WRITE_ACCESS) #define IOCTL_Device_Function 1. F. asm/ioctl.h. CTL_CODE(DeviceType,. #define IOCTL_Device_Function. FunctionCode, Method,. _IOWR(type,nr,size). FILE_ANY_ACCESS). Table 30: The I/O Control between Windows and Linux. 5.7 Memory Management Windows與Linux記憶體管理的函數，如Table 31，兩邊函數原型(Function Prototype) 幾乎完全對應。 Map. Type Include. Windows. Linux. 1. F. linux/slab.h. ExAllocatePool. kmalloc. 0. F. linux/slab.h. ExFreePool. kfree. 1. F. linux/slab.h. RtlZeroMemory. memset. 0. F. asm/uaccess.h RtlCopyMemory. copy_from_user. 0. F. asm/uaccess.h RtlMoveMemory. copy_from_user. 0. F. linux/slab.h. free_page. 1. F. linux/vmalloc.h MmMapIoSpace. ioremap. 1. F. linux/vmalloc.h MmUnmapIoSpace. iounmap. 2. F. linux/mm.h. Windows not Exist but Linux Exist. do_mmap. 0. P. linux/gfp.h. NonPagedPool. GFP_ATOMIC. 0. P. linux/gfp.h. PagedPool. GFP_KERNEL. MmFreePagesFromMdl. Table 31: The Memory Management Function between Windows and Linux. 5.8 Interrupt Windows與Linux註冊中斷的函數，如Table 32，Linux比Windows多出許多中斷函數來處理中斷，這部分需要程式設計師自己參酌是否需要加到程式中。 Map. Type Include. 1. F. linux/interrupt.h IoConnectInterrupt. request_irq. 1. F. linux/interrupt.h IoDisconnectInterrupt. free_irq. 0. P. asm/signal.h. 0 2. P F. asm/signal.h. Windows. Linux. In Function IoConnectInterrupt(). In Function request_irq(). ShareVector=FALSE. flags=SA_INTERRUPT. In Function IoConnectInterrupt(). In Function request_irq(). ShareVector=TRUE. flags=SA_SHIRQ. linux/interrupt.h Windows not Exist but Linux Exist void local_irq_save(unsigned long flags);. -39-.

(42) 2. F. linux/interrupt.h Windows not Exist but Linux Exist void local_irq_disable(void);. 2. F. linux/interrupt.h Windows not Exist but Linux Exist void local_irq_restore(unsigned long flags);. 2. F. linux/interrupt.h Windows not Exist but Linux Exist void local_irq_enable(void);. 2. F. linux/interrupt.h Windows not Exist but Linux Exist unsigned long probe_irq_on(void);. 2. F. linux/interrupt.h Windows not Exist but Linux Exist int probe_irq_off(unsigned long);. 2. F. linux/interrupt.h Windows not Exist but Linux Exist void enable_irq(int irq);. 2. F. linux/interrupt.h Windows not Exist but Linux Exist void disable_irq(int irq);. Table 32: The Interrupt Function between Windows and Linux 如Table 33所示，Windows的IoConnectInterrupt/IoDisconnectInterrupt函數對應到 Linux的request_irq/free_irq函數；在Windows的ServiceRoutine對應到Linux的handler函數，用來指定中斷時的處理常式(綠色字體)；在Windows利用ShareVector參數來判斷是否為Share Interrupt，對應到Linux函數則是利用flags參數來指定是否中斷共享(紫色字體)；Windows的Vector/Irql對應到Linux的irq(紅色字體)，指明其中斷向量；Windows的 ServiceContext對應到Linux的dev_name，指明其中斷服務常數所需要的參數(咖啡色字體)。 Windows. Linux. NTSTATUS IoConnectInterrupt(. int request_irq(. OUT PKINTERRUPT *InterruptObject,. unsigned int irq,. IN PKSERVICE_ROUTINE ServiceRoutine,. irqreturn_t (*handler)(),. IN PVOID ServiceContext,. unsigned long flags,. IN PKSPIN_LOCK SpinLock OPTIONAL,. const char *dev_name,. IN ULONG Vector,. void *dev_id);. IN KIRQL Irql, IN KIRQL SynchronizeIrql, IN KINTERRUPT_MODE. InterruptMode,. IN BOOLEAN ShareVector, IN KAFFINITY ProcessorEnableMask, IN BOOLEAN FloatingSave);. Table 33: The Interrupt Function between Windows and Linux. 5.9 Synchronization Windows與Linux的同步函數，如Table 34。Linux比Windows多出許多同步函數來處理同步，這部分需要程式設計師自己參酌是否需要加到程式中。以取得自旋鎖(SpinLock) 為例，Windows多了一個IRQ Level的參數要輸出，而Linux沒有這樣的機制，因此轉換時可將這部分忽略不處理。 Windows: VOID KeAcquireSpinLock(IN PKSPIN_LOCK -40-. SpinLock, OUT PKIRQL.

(43) OldIrql); Linux: void spin_lock(spinlock_t *lock); Map. Type Include. Windows. Linux. 0. F. asm/atomic.h. InterlockedIncrement. atomic_inc. 0. F. asm/atomic.h. InterlockedDecrement. atomic_dec. 2. F. asm/atomic.h. Windows not Exist but Linux Exist void atomic_set(atomic_t *v, int i);. 2. F. asm/atomic.h. Windows not Exist but Linux Exist int atomic_read(atomic_t *v);. 2. F. asm/atomic.h. Windows not Exist but Linux Exist int atomic_add(int i, atomic_t *v);. 2. F. asm/atomic.h. Windows not Exist but Linux Exist int atomic_sub(int i, atomic_t *v);. 2. F. asm/atomic.h. Windows not Exist but Linux Exist int atomic_inc(atomic_t *v);. 2. F. asm/atomic.h. Windows not Exist but Linux Exist int atomic_dec(atomic_t *v);. 2. F. asm/atomic.h. Windows not Exist but Linux Exist int atomic_inc_and_test(atomic_t *v);. 2. F. asm/atomic.h. Windows not Exist but Linux Exist int atomic_dec_and_test(atomic_t *v);. 2. F. asm/atomic.h. Windows not Exist but Linux Exist int atomic_sub_and_test(int i, atomic_t *v);. 2. F. asm/bitops.h. Windows not Exist but Linux Exist int set_bit(int nr, void *addr);. 2. F. asm/bitops.h. Windows not Exist but Linux Exist int test_bit(int nr, void *addr);. 2. F. asm/bitops.h. Windows not Exist but Linux Exist void clear_bit(int nr,void *addr);. 2. F. asm/bitops.h. Windows not Exist but Linux Exist void change_bit(int bit, void *addr);. 2. F. asm/bitops.h. Windows not Exist but Linux Exist int test_and_set_bit(int nr, void *addr);. 2. F. asm/bitops.h. Windows not Exist but Linux Exist int test_and_clear_bit(nr,void *addr);. 2. F. asm/bitops.h. Windows not Exist but Linux Exist int test_and_change_bit(int nr, void *addr);. 0. T. linux/types.h. KSPIN_LOCK. spinlock_t. 0. T. linux/types.h. PKSPIN_LOCK. spinlock_t *. 3. F. KeReadStateSemaphore. Windows Exist but Linux not Exist. 1. F. KeReleaseSemaphore. up. 1. F. KeInitializeSemaphore. sema_init. 1. F. KeWaitForMultipleObjects. down_interruptible. 1. F. KeWaitForSingleObject. down_interruptible. 0. F. asm/spinlock.h KeInitializeSpinLock. spin_lock_init. 1. F. asm/spinlock.h KeAcquireSpinLock. spin_lock. 1. F. asm/spinlock.h KeReleaseSpinLock. spin_unlock. 2. F. Windows not Exist but Linux Exist void spin_lock_irq(spinlock_t *lock);. 2. F. Windows not Exist but Linux Exist void spin_lock_bh(spinlock_t *lock);. 2. F. Windows not Exist but Linux Exist void spin_unlock_bh(spinlock_t *lock);. 0. F. KeAcquireSpinLockAtDpcLevel. 0. F. KeReleaseSpinLockFromDpcLevel spin_unlock. 2. F. Windows not Exist but Linux Exist void init_rwsem(struct rw_semaphore *sem);. -41-. spin_lock.

(44) 2. F. Windows not Exist but Linux Exist void down_read(struct rw_semaphore *sem);. 2. F. Windows not Exist but Linux Exist void up_read(struct rw_semaphore *sem);. 2. F. Windows not Exist but Linux Exist void down_write(struct rw_semaphore *sem);. 2. F. Windows not Exist but Linux Exist void up_write(struct rw_semaphore *sem);. 2. F. Windows not Exist but Linux Exist. 2. F. Windows not Exist but Linux Exist. void spin_lock_irqsave(spinlock_t *lock, unsigned long flags); void spin_ulock_irqrestore(spinlock_t *lock, unsigned long flags);. Table 34: The Synchronization Function between Windows and Linux. 5.10. Double Linked List. Windows與Linux的雙向鏈結函數，如Table 35所示，兩邊函數原型(Function Prototype)幾乎完全對應。 Map. Type Include. Windows. Linux. 0. F. linux/list.h. InitializeListHead. INIT_LIST_HEAD. 0. F. linux/list.h. InsertHeadList. list_add. 0. F. linux/list.h. InsertTailList. list_add_tail. 0. F. linux/list.h. IsListEmpty. list_empty. 1. F. linux/list.h. RemoveHeadList. list_move. 1. F. linux/list.h. RemoveTailList. list_move_tail. 0. T. linux/list.h. PLIST_ENTRY. list_head *. 0. T. linux/list.h. LIST_ENTRY. list_head. Table 35: The Double Linked List Function between Windows and Linux. 5.11. Timer. Windows與Linux的計時器函數，如Table 36所示。Windows平台使用KeSetTimer函數來指定時間及回呼函數(Call Back Function)而Linux則使用timer_list的結構來存放這些對應參數。 Map. Type Include. Windows. Linux. 0. F. linux/time.h. KeInitializeTimer. init_timer. 0. F. linux/time.h. KeCancelTimer. del_timer. 2. F. linux/time.h. Windows not Exist but Linux Exist. int mod_timer(struct timer_list *timer, unsigned long expires);. -42-.

(45) 1. F. linux/time.h. BOOLEAN KeSetTimer(. struct timer_list TIMER_INITIALIZER(. IN PKTIMER Timer,. _function, _expires, _data);. IN LARGE_INTEGER DueTime, _timer.expires IN PKDPC Dpc OPTIONAL. _timer.function. );. Table 36: The Timer Function between Windows and Linux. 5.12. Work Thread. Windows與Linux的工作項函數，如Table 37所示。 Map. Type Include. Windows. 1. F. linux/interrupt.h. IoAllocateWorkItem create_workqueue. 0. F. linux/workqueue.h IoFreeWorkItem. destroy_workqueue. 1. F. linux/interrupt.h. int queue_work. 3. F. linux/workqueue.h IoSizeOfWorkItem. IoQueueWorkItem. Linux. Windows Exist but Linux not Exist. Table 37: The Work Thread Function between Windows and Linux. 5.13. Module Description and Function Export. Module是Linux獨有但Windows沒有的函數，如Table 38所示，此部分會在轉換時加入，程式設計師可自行調整內容。 Map. Type Include. Windows. Linux. 2. F. linux/init.h Windows not Exist but Linux Exist. module_init(XXX_init);. 2. F. linux/init.h Windows not Exist but Linux Exist. module_exit(XXX_exit);. 2. P. Windows not Exist but Linux Exist. MODULE_AUTHOR("Undefined");. 2. P. Windows not Exist but Linux Exist. MODULE_LICENSE("GPL");. 2. P. Windows not Exist but Linux Exist. MODULE_DESCRIPTION("Undefined");. Table 38: The Module Description is Linux Only Function Function Export也是Linux才有的函數，如Table 39，此部分視程式設計師需要增加。 Map. Type Include. Windows. Linux. 2. F. Windows not Exist but Linux Exist. EXPORT_SYMBOL(name);. 2. F. Windows not Exist but Linux Exist. EXPORT_SYMBOL_GPL(name);. Table 39: The EXPORT_SYMBOL is Linux Only Function. 5.14. IRP Relative Function. 在Linux沒有Irp的封包也沒有IRQ Level，如Table 40，因此這部分可忽略不必移轉 -43-.

(46) 到Linux。 Map. Type Include. Windows. Linux. 3. F. IoFreeIrp. Windows Exist but Linux not Exist. 3. F. IoGetCurrentIrpStackLocation. Windows Exist but Linux not Exist. 3. F. IoGetNextIrpStackLocation. Windows Exist but Linux not Exist. 3. F. IoInitializeIrp. Windows Exist but Linux not Exist. 3. F. IoMakeAssociatedIrp. Windows Exist but Linux not Exist. 3. F. IoMapTransfer. Windows Exist but Linux not Exist. 3. F. IoMarkIrpPending. Windows Exist but Linux not Exist. 3. F. IoSetNextIrpStackLocation. Windows Exist but Linux not Exist. 3. F. IoSizeOfIrp. Windows Exist but Linux not Exist. 3. F. IoSkipCurrentIrpStackLocation. Windows Exist but Linux not Exist. 3. F. IRP. Windows Exist but Linux not Exist. 3. F. KeLowerIrql. Windows Exist but Linux not Exist. 3. F. KeRaiseIrql. Windows Exist but Linux not Exist. 3. F. IoCallDriver. Windows Exist but Linux not Exist. 3. F. IoCancelIrp. Windows Exist but Linux not Exist. 3. F. IoAllocateIrp. Windows Exist but Linux not Exist. 3. F. RtlInitUnicodeString. Windows Exist but Linux not Exist. 3. F. RtlUnicodeStringToAnsiString. Windows Exist but Linux not Exist. Table 40: The IRP Relative Function between Windows and Linux. 5.15. Others. Windows的SymbolicLink函數及UniCode的資料型別，Linux沒有故不處理。Windows 的字串會以L"\\Device\\DeviceName"的格式表示，因此對應到Linux要轉換為 "DeviceName"，如Table 41。 Map. Type Include. Windows. Linux. 3. F. IoCreateSymbolicLink. Windows Exist but Linux not Exist. 3. F. IoDeleteSymbolicLink. Windows Exist but Linux not Exist. 3. T. UNICODE_STRING. Windows Exist but Linux not Exist. 1. S. L"\\Device\\DeviceName". "DeviceName"7. Table 41: The Symbolic Link Function between Windows and Linux 遇誤即停的偵錯模式(Break when False)及(Memory Barrier)，如Table 42。 7. Linux 會將此裝置放在/dev/DeviceName. -44-.

(47) Map. Type Include. Windows. Linux. 0. F. assert. bugon. 0. F. asm/system.h KeMemoryBarrier. mb. 2. F. asm/system.h Windows not Exist but Linux Exist. void rmb(void);. 2. F. asm/system.h Windows not Exist but Linux Exist. void read_barrier_depends(void);. 2. F. asm/system.h Windows not Exist but Linux Exist. void wmb(void);. 2. F. asm/system.h Windows not Exist but Linux Exist. void smp_rmb(void);. 2. F. asm/system.h Windows not Exist but Linux Exist. void smp_read_barrier_depends(void);. 2. F. asm/system.h Windows not Exist but Linux Exist. void smp_wmb(void);. 2. F. asm/system.h Windows not Exist but Linux Exist. void smp_mb(void);. Table 42: The Break When False and Memory Barrier Function between Windows and Linux 如Table 43為設定執行緒(Thread)的優先權函數，雖然這兩個函數的原型一樣，只需傳入一個參數，但因Windows的kpriority參數值有32個Range，0最低 (LOW_PRIORITY)~31最高(HIGH_PRIORITY)，而Linux的nice value: 19最低~ -20最高，兩邊的定義相反，因此轉換時要做調整 Windows: KPRIORITY KeSetPriorityThread(IN PKTHREAD Thread,IN KPRIORITY Priority); Linux: void set_user_nice(task_t *p, long nice); Map. Type Include. 3. F. Windows. Linux. KeSetPriorityThread. set_user_nice. kpriority: 0(LOW_PRIORITY)~31(HIGH_PRIORITY) nice value: 19(low)~ -20(high). Table 43: Set Thread Priority between Windows and Linux. -45-.