所有不控制任何硬件设备的虚拟设备驱动程序似乎都匹配 IOResources作为IOProviderClass .
Apple 表示，与 IOResources 匹配的驱动程序附加到 IORegistry 的根以获取系统范围的服务，如 BSD 内核等...可供驱动程序使用。
我不明白的是系统如何调用您的驱动程序，因为系统不'不知道您正在控制什么设备？例如，虚拟音频驱动程序如何在不附加到系统音频混合和硬件采样缓冲区的情况下访问它？
因为我找不到任何有关IOResources的信息我在这里问的类(class)
最佳答案
我认为你问题的答案可以归结为你所问问题的内在矛盾:
All virtual device drivers who don't control any hardware devices seem to match on IOResources
对比
What I dont understand is how does your driver gets called by the system since the system doesn't know what device you are controlling?
当它是虚拟设备驱动程序时，要么有真正的设备需要控制，要么没有。对于真正的驱动程序，提供程序将是一个结点或设备对象，例如 IOPCIDevice、IOUSBDevice/IOUSBHostDevice、IOUSBInterface/IOUSBHostInterface 等。 驱动程序的提供者是您的驱动程序控制的设备。
在另一端，每个驱动程序都会通告它向操作系统、其他 kext 或用户空间进程提供的服务。这主要由驱动程序主对象的(超)类类型或它创建并在 I/O 注册表中注册的任何 nub 对象发出信号。 理解这些接口(interface)的客户端将依次将驱动程序的对象作为其提供者进行匹配。
您的音频驱动程序示例实际上演示了两种工作方式。 OS X 的音频子系统主要运行在用户空间中 - 特别是 coreaudiod。从 OS X 10.8 开始，这也包括音频设备驱动程序本身，尽管已弃用的 IOAudioDevice/IOAudioEngine 内核 API 仍然存在，并且 Apple 自 OS X 10.11 起发布了使用它的驱动程序。
在旧版/内核音频驱动程序中，您的驱动程序将实现 IOAudioDevice 和 IOAudioEngine 的子类以及可能的其他一些类。当这些类的实例在 I/O 注册表中注册时，Core Audio Daemon 会通过服务匹配机制检测到这一点，并创建用户客户端以与这些内核对象进行通信。 Core Audio 将匹配任何符合 IOAudioEngine 接口(interface)的对象 - 我认为这就是您要问的问题。
在现代音频驱动程序中，音频服务器 HAL 插件包的 Info.plist 包含 I/O 套件匹配字典。如果设备可以直接驱动，它可能直接匹配系统提供的提供程序类，例如 IOUSBInterface。对于 PCI 设备，您可能需要自定义 kext 来执行内存映射和中断处理。这个 kext 很可能只是 IOService 的子类，没有比这更具体的了，并提供自己的用户客户端类。然后，HAL 插件将匹配该 kext 的特定驱动程序类名称，并使用自定义用户客户端类打开与其的连接。
我希望这能回答您的问题？
关于macos - IO资源类，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39275210/