裝置驅動可以執行在核心態，也可以執行在使用者態，使用者態驅動的利弊網上有很多的討論，而且有些還上公升到政治性上，這裡不再多做討論。不管使用者態驅動還是核心態驅動，他們都有各自的缺點。核心態驅動的問題是：系統呼叫開銷大；學習曲線陡峭；介面穩定性差；除錯困難；bug致命；程式語言選擇受限；而使用者態驅動面臨的挑戰是：如何中斷處理；如何dma；如何管理裝置的依賴關係；無法使用核心服務等。對此，《user-space device drivers in linux: a first look》 一文有較詳細描述。
可能是為了效能優化，或者為了故障隔離，或者為了逃避開源許可證的約束，不管是基於何種目的，linux已有多種使用者態驅動的實現，如uio，vfio、usb使用者態驅動等。它們在處理中斷、dma、裝置依賴管理等方面的設計方案和實現細節上各有千秋，這是《user-space device drivers in linux: a first look》 沒有提到的，也是本文的重點。
uio 框架匯出sysfs和/dev/uiox 2套使用者態介面，使用者對裝置節點/dev/uiox進行裝置控制，mmap()介面用於對映裝置暫存器空間，write()介面用於控制中斷關閉/開啟，read()介面用於等待乙個裝置中斷。
因為對於裝置中斷的應答必須在核心空間進行，所以在核心空間有一小部分**用來應答中斷和禁止中斷，其餘的工作全部留給使用者空間處理。如果使用者空間要等待乙個裝置中斷，它只需要簡單的阻塞在對 /dev/uiox的read()操作上。 當裝置產生中斷時，read()操作立即返回。uio 也實現了poll()系統呼叫，你可以使用 select()來等待中斷的發生。select()有乙個超時引數可以用來實現有限時間內等待中斷。
uio的幾個特點：
總的來說，uio框架適用於簡單裝置的驅動，因為它不支援dma，不能支援多個中斷線，缺乏邏輯裝置抽象能力。
上文提到，uio不支援dma，所以通過dma傳輸大流量資料的io裝置，如網絡卡、顯示卡等裝置，無法使用uio框架，vfio做為uio的公升級版，主要就是解決了這個問題。通過使用者態配置iommu介面，可以將dma位址空間對映限制在程序虛擬空間中。這對高效能驅動和虛擬化場景device passthrough尤其重要。
在vfio框架中，有幾個核心概念或物件：iommu、/dev/vfio、container、iommu_group。
vfio的幾個特點：
usbfs(usb file system)提供了一些在使用者空間下操作usb裝置的函式介面和資料結構, 在開發使用者態驅動時, 可以直接利用這些函式介面來實現對 usb 裝置的控制和資料傳輸。
libusb對usb file system提供的函式介面和資料結構進行了封裝, 可以有效減少程式中函式和資料結構使用不當造成的錯誤。libusb 對 usb 裝置的訪問提供了兩種機制, 同步訪問和非同步訪問。
khubd是核心後台執行緒，用來管理監視usb hub的狀態, 一旦發生熱插拔就會喚醒這個執行緒, 進而新增或者移除裝置，並傳送netlink訊息傳遞給使用者態空間。
usb 使用者態驅動框架的幾個特點：
linux kernel v4.4
user-space device drivers in linux: a first look
user-mode driver framework
vfio introduction
linux iommu和vfio概念空間解構
linux核心態使用者態
概述 linux系統使用者態和核心態相關知識，linux核心版本為3.10.79。使用者態和核心態定義 核心態 cpu可以訪問記憶體所有資源,包括外圍裝置.可以進行處理器工作模式切換，程式的切換。使用者態 只能受限的訪問記憶體,且不允許訪問外圍裝置，不可以進行處理器模式切換。為什麼分使用者態和核心態...
通過使用者態驅動來讀寫spi 裝置
當有乙個spi device的時候，但是不想再核心態寫spi driver的話，可以使能config spi spidev 這樣的話會生成乙個spidev.ko 插入這個ko後就可以在使用者態open dev spidev0.0 o rdwr 的方式pen 這個裝置 然後通過spi ioc wr m...
Linux 核心態與使用者態
使用者態 ring3 執行於使用者態的 則要受到處理器的諸多檢查，它們只能訪問對映其位址空間的頁表項中規定的在使用者態下可訪問頁面的虛擬位址，且只能對任務狀態段 tss 中i o 許可位圖 i o permission bitmap 中規定的可訪問埠進行直接訪問 核心態 ring0 在處理器的儲存保...