POSIX 原始读/写
谁能解释一下使用 BSD read() write() 操作在 /dev 节点上执行的读/写操作如何到达 HDD。
它是通过文件系统还是直接通过设备驱动程序交互......
Can anyone explain how the read/write operations performed on /dev node using BSD read() write() operation reaches the HDD.
Does it go thru File System or It directly interacts thru the device drivers....
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
它直接与设备驱动程序交互。有些操作系统（不确定 OS X）会使用缓冲区高速缓存，但有些操作系统会绕过它。在某些情况下，它甚至取决于设备节点。例如，OS X 具有 /dev/disk* 以及 /dev/rdisk*，其中 rdisk* 设备节点是原始访问。
It directly interacts with the device driver. Some operating systems (not certain about OS X), will put use the buffer cache, but some will bypass it. In some cases, it even depends on the device node. For example, OS X has /dev/disk* as well as /dev/rdisk*, where the rdisk* device nodes are raw access.
例如，考虑以下情况。您打开虚构的 /dev/bd 设备，它是一个 HDD。内核为了服务系统调用请求，首先尝试查找与 /dev/bd 路径关联的 inode。成功后，正在确定，inode的类型是什么，刚才已经读取到了。在我们的例子中，索引节点的类型将是块特定的。此时，内核知道这个inode代表一个驱动程序（块特定设备的驱动程序）。每个设备都有一个关联的 (major_id,minor_id) 对，它们标识不同的设备。在inode中，可以找到它，并且内核确切地知道哪个驱动程序可以服务该请求。并且根据请求，将调用驱动程序的适当功能（例如读取）。
For example, take the following case. You open the fictional /dev/bd device, which is a HDD. The kernel, in order to serve the system call request, first take an attempt to find the inode associated with the /dev/bd path. After it succeeded, it's being determined, what is the type of the inode, has been read just now. In our case, the type of the inode will be BLOCK-SPECIFIC. At this point, the kernel knows that this inode represents a driver(a block-specific device's driver). Every device has a (major_id,minor_id) pair associated, they identify the different devices. In the inode, it can be found, and the kernel knows exactly, which driver can serve the request. And depends on the request, the appropriate function of the driver will be invoked(for example read).