※ 引述《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