Survey Report For User Space Driver In Linux
R98922062 魏潔紋 R98922017 洪崇耕
1. Introduction
我們先敘述一下傳統常見的兩種系統架構，接著會再介紹 User Space Driver 的架構。[1]
Fig1. Monolithic kernel and Microkernel architecture
Linux kernel 是類似 Monolithic kernel 的架構，在這架構下，所有的系統服務 如 memory management, process scheduling, filesystem, subsystem, device drivers 都 是在 kernel space 裡執行。
對驅動程式而言，這樣做的好處是驅動程式有最高的權限可以順利的完成工 作，可以存取整個記憶體，因此要對不須要額外的複製或搬移，少掉很多 overhead，
有著比較好的執行效能。缺點是所有程式都在 kernel space 裡，一個 bug 就有可 能讓整個系統無法運作。
而 Microkernel 是另一種常見的架構。在此架構下，kernel 只提供最基本的 系統服務如 memory management, process scheduling，而 subsystem, filesystem,
device drivers 等服務都透過 user space process 的方式提供，這種系統必須靠大量 的 IPC 在不同 process 之間做通訊才能運作。
對驅動程式而言，此種架構因為有大量的 IPC 以及 context switch, mode switch，這些 overheads 會造成效率下降，但是這樣的做法可以讓 kernel 有好的 flexibility 跟 stability，視需求而執行不同服務程式即可更改服務內容，而且就算 驅動程式當掉了，並不會造成 kernel panic，把當掉的程式換掉，系統即可恢復 正常。
Fig2. User Space Driver Architecture in Linux
User Space Driver 指的是在 user space 上執行讓驅動程式，在 Microkernel 的 架構下，所有的驅動程式都是 User Space Driver，但是 Linux 比較偏向 Monolithic kernel 架構，因此 Linux 下的 User Space Driver，是一種 Hybrid 的架構，介在兩 者之間，以下描述此種架構。
因為 Linux 並沒有透過 IPC 直接呼叫 Driver 的方法，依然必須在 kernel space 裡留 Shadow Driver，Shadow Driver 負責將收到的工作 redirect 到 Master Space Driver，以解決沒有 IPC 使用 Driver 的問題。而 Master Driver 在收到工作後，開 始執行驅動程式負責的運算及處理，處理完後，可以將資料直接對硬體做 I/O，
或者傳控制命令進 Shadow Driver，讓 Shadow 幫忙在 kernel space 裡做 I/O。Shadow Driver 等 Master Driver 完成工作後，就將結果傳回去給 Application。在這種架構 下，如果實做得宜，原本的 Application 還是使用原來的 interface 去跟系統送出
I/O Request，不需要修改就可以使用，須要修改的部分只有驅動程式的地方。
在 Linux 正式提供支援之前，就已經有這方面的研究[2,3,4]，都是透過對 kernel 做 patch，提供自己的 API 給 Master Driver 使用來達到 UIO，真正的實做 的方法因人而異，沒有一種設計是完美的做法，所以不在這邊介紹它們的設計，
但我們將可以用的 User/Kernel Interface 整理於第三節[8]。雖然不一一介紹它們 的設計，但這些設計只要是在解決下列這些議題：
1.如何把 Interrupt 導去 userspace process 2.如何讓 Process 有控制硬體的權限
3.支援 DMA 的系統，必須要做 memory page pinning 跟 address translation 4.User/Kernel Space 之間如何有效率的傳遞資料
Linux 在 2.6.24 之後提供了 User Space I/O(UIO)的架構[5,6]，但是目標是針 對 Industry Card，此種 device 的共同特性是透過 memory 的存取就可以完整控制 這個硬體，且這種硬體當有資料時會產生 interrupt。UIO 為這個 scenario 做了特 別的設計，所以如果是這種情況，它可以處理的很好，可是對於其他的使用情況，
能提供的支援有限，因此並不常被拿來使用。
2. Pros and Cons
在這一節，我們說明了使用 UIO 這架構帶來的優點及缺點[4,6,7]
Pros
Ease of development
以往的驅動程式通常須要經過訓練，對 kernel programming 有一定 的熟悉度才能進行開發，而 User Space Driver 除了它做的工作是 Driver 之外，其他部分跟一般的應用程式一樣，寫起來沒什麼不同，而且也可 以使用普通的 debug tool 進行 debug，這降低了開發 UIO 的難度。
Stability
研究指出，有很大一部份的當機是來自於 Driver 的 defect，而只有 一小部分是 kernel 本身造成的，因此把驅動程式移到 User space 上，可 以讓 kernel 更 simple，減少來自於 Driver 產生的當機，以提供更好的穩 定度。
Reliability
這一點跟 Stability 很像，但 Reliability 是指 User Space Driver 就算 Crash 了，也比較不會讓 kernel panic，因此 kernel 可以繼續提供其他的 服務，而 Driver 只要 fix 過後重新啟動，系統就可以恢復正常。
Maintainability
User/Kernel interface 相較於 in-kernel interface 的改變速度來說較緩 慢，因此 User Space Driver 在每次 kernel 更新後，並不須要重寫 Driver 去使用新的 kernel interface 或著重新 compile 成新版 kernel 用的 driver。
Cons
Timing
User Space Driver 因為是一支普通的 user process，在沒有特別的調 整之下，它必須跟所有 process 去爭 CPU，這會導致我們無法準確預測 request 何時會被執行。另一個缺點是 interrupt 的 response time，因為多 了一次的 mode 跟 context switch，所以它的 response time 比 kernel 還要 長，如果沒有妥善處理，這會造成效能的問題。
Functionality
雖然在 User Level 可以做 floating point 的運算以及自由的使用其他 Library，但是因為 mode protection 的關係，在 User Level 也有許多限制，
導致有些在 Kernel Level 可以輕易做到的事情在 User Level 沒辦法做，
這會須要一些額外的 effort 去克服這問題。
Security
跟剛剛的 Functionality 是同一件事情的不同角度，在 User Level 可 以做的事情越多，那麼系統的保護就越少，但是我們為了做到 UIO，不 得不提供一些方法讓 User Space Driver 使用，這間接的為 Kernel 增加了 一些安全性的問題。另外在 User Space Level，系統無法提供非常好的 安全保護給 Driver，僅能做有限的保護。
3. User / Kernel Interface
在 Linux 的世界中，有很多方式能讓 User Space 和 Kernel Space 之間進行溝 通。主要分成 Kernel Interface、Socket Based Mechanism、Ioctl、Kernel System calls、
Sending Signals from the Kernel to User Space、Upcall and Shared Memory。接下來 我們會介紹這些溝通方法的主要架構和其優缺點。
1. Kernel Interface
此類的溝通方式，會提供一個 RAM based file system，使用者在 User Space 可以使用 write or read operation 存取此 file system 內的 value。
其中比較常用的又分為 Procfs 和 Debugfs。
A. Procfs
Design for export process information，例如包含 Current Status 和已經被使用過的 File descriptors。
B. Debugfs
Design for debugging purpose，且為 RAM based file system。當 使用者需要較多的 debugging information 時，建議使用 Debugfs 來 取代 Procfs；Debugfs 有很大的使用彈性，主要包含兩種特性: (1) One line code to read/write single value (2) Write your own read/write function。
Conclusion：此類的溝通方是好處在於，在 User Space 上有很多 Tools 可以 Send data 到 Kernel Spcae 上，例如 cat()、echo()等方式，對使用者 來講對於這些 tools 有一定的熟悉度。但缺點是沒有好的即時通知性，
意思是除非 User program 去 access 此 file，否則他將不會主動知道此 file 有無任何的更改。
2. Socket Based Mechanisms
在實作方面會先 setup socket，並且產生一個 work queue 來記錄需 要處理的工作，也會提供 callback function(executed in interrupt context)，
最後在處理完工作後將 answer 從 socket 在 send 回去 application。主要 介紹 UDP socket and Netlink Socket。
A. UDP
Usage is well known B. Netlink
Netlink 主要的好處在於提供 full-duplex communication link，
因為這種方式有新增一些 source code 在 kernel 內所以必須重 新 compile kernel 才可以使用。
Conclusion：優點是允許 Application 去 listen on a socket，且 Kernel 可 以在任何時候 send message 到 socket 上，此溝通機制讓 User Space 和 Kernel Space 的角色趨於平等。
3. Ioctl
Design for device drivers，ioctl 的做法是 send command to driver。有 四種 type 可以用不同參數來設定功能(1)Do not require any data (2)Write some data to the kernel (3)Read some data from kernel (4)Kernel module reads the data and exchange it with some new data。
4. Kernel System Calls
此類溝通發生於當 User space program 希望 Linux kernel 提充一些
service or some data 時使用。Invoked by wrapper function by glibc and 必 須重新 compile kernel。
5. Sending Signals from the Kernel to User Space
比較特別是這類的 communication，只發生在 kernel send signals to user space，所以必須知道 the pid of the user process 才可以確認此 signal 送到的位置為正確。Send signal 的流程為(1)Update the process descriptor (2)Check pending signal。在 Kernel space 和 User space 都有彼此的事情要 負責：
A. Kernel
Create and set up sig_info
Obtained PID of user process
Send signal by send_sig_info B. User
Register signal handler
Report PID to kernel module
Wait signals 6. Upcall
Linux kernel提供了kernel module啟動一個在user space執行的程式，
除此之外還可以傳遞參數給程式，並且提供了簡單的同步機制，讓kernel module自行選擇什麼條件下才要繼續往下執行。因此在kernel裡如果須 要用到某些Library，可以透過這機制把運算丟去user space做。
7. Shared memory
Linux 也支援 User/Kernel 之間共享記憶體空間，通常這是最有效的資料 傳輸方式，因為所以的傳輸都是透過直接存取記憶體，不會有任何的資料 copy 產生。它的缺點是須要額外的機制去做 Notification 以及解決
Concurrency Issue。
4. Summary and Comments
我們先介紹了 Monolithic Kernel 以及 Microkernel 的架構，然後由此說明 User Space Driver in Linux 的概念以及它與傳統架構之相似相異之處，以提到了過去 及現在的發展現況。在第二節中說明了使用 UIO model 的優缺點，讓我們在選擇 要不要採取 UIO 時的考量依據，第三節整理了現有 Linux 的 user/kernel interface 可以做到的事情，提供我們在設計時的依據。
做完了此次的 Survey，我們覺得 UIO 現在遇到的主要問題在於它有比較高 的 overheads，導致效能不及傳統的 kernel driver。但是我們覺得 UIO 在未來有它 的潛力存在，因為只要使用 well-design 的 IPC mechanism，process 之間可以有效 率的傳輸資料或通訊，加上現代的電腦運算能力越來越高，記憶體空間也越來越 大，一次 Request 的處理時間會越來越低，一次能傳輸的資料量也越來越大，可 以把 Context 及 Mode switch 的 overhead 分攤掉，這樣 UIO 就足以應付絕大部份 的 Driver 的效能要求，在不嚴重影響效能的情況下，而可以得到良好的 System Stability 和 Reliability，我們相信一般使用者在效能差不多的情況下，會選擇 UIO 的作法。
而從 driver programmer 的角度來看，只要可以解決初期遇到的 user/kernel 之間通訊及 access permission 的問題，使用 UIO Model 可以減少程式開發及除錯 的難度，也減少了 driver 維護及移植所需的時間，UIO Model 應該也會成為 driver programmer 的一種新選擇。
Reference:
[1] Benjamin Roch, and TU Wien. Monolithic kernel vs. Microkernel.
[2] Hari Krishna Vemuri. Userdev: A Framework For User Level Device Drivers In Linux. Apr 2002
[3] Jeremy Elson. FUSD : A Linux Framework for User-Space Devices. Aug 2003.
[4] Peter Chubb. Linux kernel Infrastructure for User-Level Device Drivers. Linux Conference, Adelaide, Australia. Jan 2004
[5] Hans-Jurgen Koch. The Userspace I/O HOWTO. Dec 2008
[6] Eva-Katharina Kunst, and Jurgen Quade. Driver Shift - Userspace drivers in the new Linux kernel. Linux-magazine, Issue 86, pages 28-31, Jan 2008
[7] Ben Leslie, Peter Chubb, et al. User-level Device Drivers: Achieved Performance.
Journal of Computer Science and Technology, Volume 20, pages 654-664, Sep 2005 [8] Ariane Keller. Kernel Space - User Space Interfaces.
http://people.ee.ethz.ch/~arkeller/linux/kernel_user_space_howto.html
