IO资源类

Question

所有不控制任何硬件设备的虚拟设备驱动程序似乎都IOResources与IOProviderClass.
Apple 表示，匹配的驱动程序IOResources会附加到 IORegistry 的根目录，以获得可供驱动程序使用的系统范围服务，例如 BSD 内核等。
我不明白的是，由于系统不知道您正在控制什么设备，系统如何调用您的驱动程序？例如，虚拟音频驱动程序如何在不附加到系统音频混合和硬件采样缓冲区的情况下访问它？
由于我找不到有关该IOResources课程的任何信息，因此我在这里询问

Answer 1

我认为你问题的答案可以归结为你所问问题的内在矛盾：

所有不控制任何硬件设备的虚拟设备驱动程序似乎都在 IOResources 上匹配

与

我不明白的是，由于系统不知道您正在控制什么设备，系统如何调用您的驱动程序？

当它是虚拟设备驱动程序时，要么有真正的设备需要控制，要么没有。对于真正的驱动程序，提供程序将是一个结点或设备对象，例如 IOPCIDevice、IOUSBDevice/IOUSBHostDevice、IOUSBInterface/IOUSBHostInterface 等。驱动程序的提供者是您的驱动程序控制的设备。

在另一端，每个驱动程序都会公布它向操作系统、其他 kext 或用户空间进程提供的服务。这主要由驱动程序主对象的（超）类类型或它创建并在 I/O 注册表中注册的任何 nub 对象发出信号。理解这些接口的客户端将依次将驱动程序的对象作为其提供者进行匹配。

您的音频驱动程序示例实际上演示了两种工作方式。OS X 的音频子系统主要运行在用户空间 - 特别是coreaudiod. 从 OS X 10.8 开始，这也包括音频设备驱动程序本身，尽管已弃用的 IOAudioDevice/IOAudioEngine 内核 API 仍然存在，并且 Apple 自 OS X 10.11 起发布了使用它的驱动程序。

在遗留/内核音频驱动程序中，您的驱动程序将实现 的子类IOAudioDevice，并且IOAudioEngine可能还实现一些其他类。当这些类的实例在 I/O 注册表中注册时，Core Audio Daemon 会通过服务匹配机制检测到这一点，并创建用户客户端以与这些内核对象进行通信。核心音频将匹配符合IOAudioEngine接口的任何对象 - 我认为这就是您要问的问题。

在现代音频驱动程序中，音频服务器 HAL 插件包的 Info.plist 包含 I/O 套件匹配字典。如果设备可以直接驱动，它可能直接匹配系统提供的提供程序类，例如 IOUSBInterface。对于 PCI 设备，您可能需要自定义 kext 来执行内存映射和中断处理。这个 kext 很可能只是 IOService 的子类，没有比这更具体的了，并提供自己的用户客户端类。然后，HAL 插件将匹配该 kext 的特定驱动程序类名称，并使用自定义用户客户端类打开与它的连接。

我希望这能回答你的问题？