※ 引述《jserv (松鼠)》之銘言：
: ※ 引述《jserv (松鼠)》之銘言：
: : 其實，Linux kernel source 裡面的 Documentation/filesystems/vfs.txt 就給了
: : 相當好的闡述，應該先思考哪些是本質性的設計考量，而不是一直在細節上打轉，這樣
: : 可能會陷入似是而非的論述中。
: 補充幾點：
: . 隨著 Linux kernel 2.6.23 的 UIO (Userspace I/O) 的出現，有一致的 userspace
: I/O interface for driver，這意味著，driver 的運作是可「幾乎」於 userspace
: ，所以，前文提及 syscall 與 kernel/user-space 的切換，不過是個面向罷了。
=======
user space 的 process/thread 直接掌控 I/O , 這跟 Virtual Machine (如
VMware , 雖然她不是硬體支援的 VMM, 但效果逼近) 讓 guest OS 及其 driver
(並不全然是原來 guest os 的 driver) 在 user space 逼真到好像可以直接執
行, 就如同在 user space 的 I/O driver 可以直接驅動 I/O device .
user space 的 I/O driver 使用 I/O 可以是改進為授權專用, 以配屬方式撥給
或輪換似的直接控制 I/O port . 或是跟往日一樣是得透過 kernel OS 代理 或
者是透過類似 Virtual Memory 的 Mapping Translation 硬體轉換與查驗才能取
得使用, 目前應該是沒有一致的說法(可能是公司發展的機密).
輸出採直接控制不難, 但輸入要從硬體通知到 user space process/thread 就
得更改 interrupt 的形式. 如果因此不必做 context switch 的動作, 這將是
很大的 architecture 改變 !
: . UIO 主要由日系大廠提出，並成功整合到 Kernel 的設計，現在已有頗多成功案例，
: 而過去的 xserver-video-driver 與 libusb 也被視為 userspace driver 的先驅
: . 無論是 UIO 抑或傳統的 driver I/O model，其實都在提供以下三個機制：
: * interrupt handling
: * I/O memory access
: * continuous memory allocation
: . 顯然，UIO 的優勢在於 copyless I/O 與 userspace 對 event 的掌握 (via sysfs)
: 但即便 Linux kernel 近來引入頗多重大修改，但本質的設計考量卻仍是一致的，這才是
: 該去優先思考的地方。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.115.4.12