IOKit驱动已加载未启动问题及修改生效原因咨询

问题背景梳理 #

先帮你理清楚整个场景的关键信息：

• 你有两个关联的IOKit驱动：
  • 基础驱动：继承IOResources，无硬件触发逻辑，通过IOServiceOpen向用户态提供服务
  • 派生驱动：原本是存放于/Library/Extensions的通用内核扩展，通过OSBundleLibraries声明了对基础驱动的依赖
• 最初状态：基础驱动加载时会自动触发派生驱动加载，也能通过kextcache预加载
• 修改后出现的问题：将派生驱动的IOProviderClass也改为IOResources后，虽然kextstat显示两个驱动都已加载，但ioreg里只有基础驱动有活跃实例，派生驱动的IOService::startCandidate从未被调用，最终还会因闲置被内核移除

为什么修改基础驱动的IOProviderClass能解决问题？ #

这要从IOKit的服务匹配机制说起：

1. IOResources的特殊定位：IOResources是系统级的单例服务，作用是给无硬件依赖的驱动提供一个"锚点"。但如果多个驱动都把它设为IOProviderClass，IOKit的匹配器会把它们当成独立的服务来处理，无法识别你代码层面的依赖关系——OSBundleLibraries只是保证派生驱动能链接到基础驱动的代码，不控制IOKit服务的启动顺序和匹配触发逻辑。这种情况下，内核无法确定哪个驱动先启动、哪个驱动需要等待另一个，导致派生驱动的匹配流程卡在probeCandidates阶段，无法进入启动环节。
2. 修改后的链式匹配逻辑：当你把基础驱动的IOProviderClass改为派生驱动的类时，相当于给IOKit明确了一个清晰的依赖链：
   • 派生驱动先绑定IOResources实例并启动，成为一个活跃的服务节点
   • 基础驱动以派生驱动的活跃服务为Provider，IOKit会在派生驱动启动完成后，自动触发基础驱动的匹配和启动流程
   • 这种明确的父子服务关系，让内核能正确处理两个驱动的启动顺序，最终两者都能在ioreg中显示为活跃实例

原设计是否合规？ #

原设计（两个驱动都以IOResources为IOProviderClass）并不符合IOKit的依赖匹配规范：

• 虽然两个驱动都能被加载，但IOKit无法识别它们之间的依赖逻辑，派生驱动没有明确的触发条件来启动自身的服务实例
• 没有活跃服务实例的驱动，会被内核判定为闲置，一段时间后就会被自动移除

总结最佳实践 #

• 对于有依赖关系的无硬件IOKit驱动，建议构建链式匹配结构：让依赖方（基础驱动）以被依赖方（派生驱动）的服务类作为IOProviderClass，明确启动顺序
• 不要混淆OSBundleLibraries和IOKit服务匹配的作用：前者是代码层面的链接依赖，后者是服务实例的启动依赖
• 避免多个有依赖的无硬件驱动同时锚定IOResources，否则会导致匹配流程混乱，服务无法正常启动

内容的提问来源于stack exchange，提问作者user7256215