我很好奇司机如何工作。我确实理解基本概念以及单个驱动程序如何运作。我感到困惑的是，当涉及多个司机时，他们的工作方式。
让我通过一个例子解释我的问题：
假设我在HW中有一个PCIe和USB接口。主机的主要接口（驱动程序，操作系统，应用程序所在的位置）是PCIe。 USB接口可通过PCIe主机访问。
所以，在这种情况下，我会为PCIe以及USB提供驱动程序。 当数据必须通过应用程序通过USB传输时，应用程序将调用系统/ OS调用。这最终会出现在USB驱动程序中。 这是对的吗？
USB驱动程序完成处理后，必须调用PCIe调用。谁做到了？是操作系统还是USB驱动程序本身？ 我认为，它将是操作系统，否则它将破坏基本的模块化哲学。但是调用操作系统的驱动程序似乎违反直觉，因为我总是假设流程从应用程序到操作系统再到驱动程序和硬件。
任何人都可以对这个话题有所了解吗？
答案 0 :(得分：1)
与用户空间代码非常相似，存在用于访问内核域中各种类型硬件的标准化API（具体用法因操作系统而异）。因此，对于一个设备驱动程序而言，通过这些标准化API访问另一个设备的驱动程序并不是一件容易的事。 （警告：USB是一个非常复杂的协议，许多细节已被掩盖，以保持较长的帖子）
最初的问题集中在PCIe到USB卡上。在这个例子中，我认为考虑到有三个＆＃34;层是有帮助的。司机第一层是PCIe总线控制器驱动程序，它控制PCIe总线特定功能，例如为PCIe设备映射MMIO以及支持来自这些PCIe设备的中断。第二层是USB主机控制器层，它提供发布标准化USB事务的功能。最后，使用标准化USB事务，USB设备驱动程序（如USB驱动程序键盘）位于堆栈顶部，以实现特定USB外围设备的功能。来自键盘驱动程序的调用将调用USB主控制器驱动程序中的功能，这反过来甚至可以调用PCIe驱动程序。所有这些都在内核空间中完成，即使使用了许多单独的驱动程序。
大多数PCIe设备通过MMIO访问与CPU进行大量通信，这些访问显示为对处理器的内存读/写。通常，不需要特定的驱动程序功能来执行从PCIe到CPU的MMIO数据传输（尽管可能有一些简单的访问函数来进行字节序校正或处理缓存问题）。
USB主控制器驱动程序的有趣之处在于它们符合标准（例如XHCI，USB 3.0标准，我将在本例中使用），它规定了标准设备内存映射和行为。因此，通常存在一些芯片专用驱动器对USB主机控制器设备执行非标准初始化。此外，这些特定于芯片的驱动程序将检索XHCI标准化MMIO区域的位置，并提供从XHCI控制器接收中断的方法（在本例中来自PCIe中断）。
接下来，将此标准化内存区域和中断机制传递给通用XHCI主机控制器驱动程序。通用的XHCI代码并不关心设备是否是PCIe，它只关心它是否通过了遵循XHCI标准的内存区域并且它接收到正确的中断XHCI驱动程序提供了通用USB传输功能，而USB接口也是USB键盘设备可用于启动USB事务。
在大多数情况下，XHCI驱动程序只是对传入的MMIO区域进行读/写操作。这允许相同的通用XHCI代码为宽阵列USB主机控制器提供服务，其中许多不是PCIe设备。从而有效地允许XHCI驱动程序抽象出实现USB控制器的底层硬件。因此，对于原始问题提出的示例，USB主机控制器标准旨在隐藏底层硬件机制，以实现更模块化的USB驱动程序系统。