## 2.9.?在用戶空間做 一個第一次涉及內核問題的 Unix 程序員, 可能會緊張寫一個模塊. 編寫一個用戶程序來直接讀寫設備端口可能容易些. 確實, 有幾個論據傾向于用戶空間編程, 有時編寫一個所謂的用戶空間設備驅動對比鉆研內核是一個明智的選擇. 在本節, 我們討論幾個理由, 為什么你可能在用戶空間編寫驅動. 本書是關于內核空間驅動的, 但是, 所以我們不超越這個介紹性的討論. 用戶空間驅動的好處在于: - 完整的 C 庫可以連接. 驅動可以進行許多奇怪的任務, 不用依靠外面的程序(實現使用策略的工具程序, 常常隨著驅動自身發布). - 程序員可以在驅動代碼上運行常用的調試器, 而不必走調試一個運行中的內核的彎路. - 如果一個用戶空間驅動掛起了, 你可簡單地殺掉它. 驅動的問題不可能掛起整個系統, 除非被控制的硬件真的瘋掉了. - 用戶內存是可交換的, 不象內核內存. 一個不常使用的卻有很大一個驅動的設備不會占據別的程序可以用到的 RAM, 除了在它實際在用時. - 一個精心設計的驅動程序仍然可以, 如同內核空間驅動, 允許對設備的并行存取. - 如果你必須編寫一個封閉源碼的驅動, 用戶空間的選項使你容易避免不明朗的許可的情況和改變的內核接口帶來的問題. 例如, USB 驅動能夠在用戶空間編寫; 看(仍然年幼) libusb 項目, 在 libusb.sourceforge.net 和 "gadgetfs" 在內核源碼里. 另一個例子是 X 服務器: 它確切地知道它能處理哪些硬件, 哪些不能, 并且它提供圖形資源給所有的 X 客戶. 注意, 然而, 有一個緩慢但是固定的漂移向著基于 frame-buffer 的圖形環境, X 服務器只是作為一個服務器, 基于一個內核空間的真實的設備驅動, 這個驅動負責真正的圖形操作. 常常, 用戶空間驅動的編寫者完成一個服務器進程, 從內核接管作為單個代理的負責硬件控制的任務. 客戶應用程序就可以連接到服務器來進行實際的操作; 因此, 一個聰明的驅動經常可以允許對設備的并行存取. 這就是 X 服務器如何工作的. 但是用戶空間的設備驅動的方法有幾個缺點. 最重要的是: - 中斷在用戶空間無法用. 在某些平臺上有對這個限制的解決方法, 例如在 IA32 體系上的 vm86 系統調用. - 只可能通過內存映射 /dev/mem 來使用 DMA, 而且只有特權用戶可以這樣做. - 存取 I/O 端口只能在調用 ioperm 或者 iopl 之后. 此外, 不是所有的平臺支持這些系統調用, 而存取/dev/port可能太慢而無效率. 這些系統調用和設備文件都要求特權用戶. - 響應時間慢, 因為需要上下文切換在客戶和硬件之間傳遞信息或動作. - 更不好的是, 如果驅動已被交換到硬盤, 響應時間會長到不可接受. 使用 mlock 系統調用可能會有幫助, 但是常常的你將需要鎖住許多內存頁, 因為一個用戶空間程序依賴大量的庫代碼. mlock, 也, 限制在授權用戶上. - 最重要的設備不能在用戶空間處理, 包括但不限于, 網絡接口和塊設備. 如你所見, 用戶空間驅動不能做的事情畢竟太多. 感興趣的應用程序還是存在: 例如, 對 SCSI 掃描器設備的支持( 由 SANE 包實現 )和 CD 刻錄器 ( 由 cdrecord 和別的工具實現 ). 在兩種情況下, 用戶級別的設備情況依賴 "SCSI gneric" 內核驅動, 它輸出了低層的 SCSI 功能給用戶程序, 因此它們可以驅動它們自己的硬件. 一種在用戶空間工作的情況可能是有意義的, 當你開始處理新的沒有用過的硬件時. 這樣你可以學習去管理你的硬件, 不必擔心掛起整個系統. 一旦你完成了, 在一個內核模塊中封裝軟件就會是一個簡單操作了.