Apple - IOKit Fundamentals

本文翻译整理自：IOKit Fundamentals （Updated: 2014-04-09
https://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Introduction/Introduction.html

文章目录

[一、I/O Kit 基础知识简介](#一、I/O Kit 基础知识简介)
- 1、谁应该阅读本文档？
- 2、本文档的组织
- 3、也可以看看
[二、什么是 I/O Kit ？](#二、什么是 I/O Kit ？)
- 1、在你开始之前
- [2、I/O Kit 功能](#2、I/O Kit 功能)
- [3、I/O Kit 的设计原则](#3、I/O Kit 的设计原则)
- [4、I/O Kit 的局限性](#4、I/O Kit 的局限性)
- 5、语言选择
- - [在 I/O Kit 驱动程序中使用命名空间](#在 I/O Kit 驱动程序中使用命名空间)
  - [在 I/O Kit 驱动程序中使用静态构造函数](#在 I/O Kit 驱动程序中使用静态构造函数)
- [6、I/O Kit 的部件](#6、I/O Kit 的部件)
- - 框架和库
  - 应用程序和工具
  - [其他 I/O Kit 资源](#其他 I/O Kit 资源)
- 7、您应该在内核中编程吗？
- - 代码何时应驻留在内核中
  - 内核驻留代码的替代方案
三、架构概述
- 1、驱动程序分层
- - [amilies and Drivers](#amilies and Drivers)
  - 驱动程序和核心
  - [I/O 连接的剖析](#I/O 连接的剖析)
- 2、设备驱动程序的运行环境
- - 运行时功能
  - 内核编程约束
- [3、I/O 注册表和 I/O 目录](#3、I/O 注册表和 I/O 目录)
- 4、驱动程序匹配
- [5、I/O Kit 类层次结构](#5、I/O Kit 类层次结构)
- - 操作系统类
  - [通用 I/O Kit 类](#通用 I/O Kit 类)
  - [I/O Kit 系列类](#I/O Kit 系列类)
- 6、从内核外部控制设备
- - 设备接口机制
  - [POSIX 设备文件](#POSIX 设备文件)
[四、I/O 注册表](#四、I/O 注册表)
- [1、I/O 注册表架构和构造](#1、I/O 注册表架构和构造)
- [2、I/O 注册表资源管理器](#2、I/O 注册表资源管理器)
五、驱动程序和设备匹配
- [1、Driver Personalities和匹配语言](#1、Driver Personalities和匹配语言)
- 2、驱动程序匹配和加载
- 3、设备匹配
六、基类
- [1、libkern 基类](#1、libkern 基类)
- - 对象创建和处置（OSObject）
  - - 对象构造
    - 对象保留和处置
  - 运行时类型信息（OSMetaClass）
  - - 对象构造和动态分配
    - 类型转换、对象自检和类信息
  - [在 libkern 中定义 C++ 类](#在 libkern 中定义 C++ 类)
- [2、I/O Kit 基类](#2、I/O Kit 基类)
- - 动态驱动程序注册（IORegistryEntry）
  - 基本驱动行为 (IOService)
  - - 驱动程序对象生命周期
    - 供应商匹配
    - 通知和消息
    - 驱动程序访问器
    - [其他 IOService 功能](#其他 IOService 功能)
[七、I/O Kit 系列](#七、I/O Kit 系列)
- [1、 Drivers 和 Families](#1、 Drivers 和 Families)
- [2、 families 就是 library](#2、 families 就是 library)
- - 库版本控制
  - 库加载
- [3、 families 的程序结构](#3、 families 的程序结构)
- - 典型类别
  - 命名和编码约定
- [4、创建 I/O Kit 系列](#4、创建 I/O Kit 系列)
八、处理事件
- 1、工作循环
- 2、事件源
- - 处理中断
  - - [I/O Kit 中的中断处理](#I/O Kit 中的中断处理)
    - 设置附加到工作循环的中断处理程序
    - 过滤中断事件源
    - 使用没有工作循环的中断处理程序
  - 处理计时器事件
  - [I/O 请求和命令门](#I/O 请求和命令门)
  - - 上涨呼叫和下跌呼叫
    - 设置和使用命令门
九、管理数据
- [1、处理 I/O 传输](#1、处理 I/O 传输)
- - 内存描述符和内存游标
  - [I/O 请求中的内存](#I/O 请求中的内存)
  - [64 位系统架构的问题](#64 位系统架构的问题)
  - - [64 位系统架构上的地址转换](#64 位系统架构上的地址转换)
    - [在 64 位系统架构上支持 DMA](#在 64 位系统架构上支持 DMA)
- [2、中继 I/O 请求](#2、中继 I/O 请求)
- 3、有关内存描述符的更多信息
- 4、有关记忆游标的更多信息
- - [DMA 和系统内存](#DMA 和系统内存)
  - 处理硬件限制
  - [IOMemoryCursor 子类](#IOMemoryCursor 子类)
十、管理电源
- 1、电力活动
- 2、电源平面：电源依赖关系的层次结构
- 3、设备和电源状态
- 4、确定如何在驱动程序中实现电源管理
- 5、实现基本电源管理
- 6、实施高级电源管理
十一、管理设备移除
- 1、设备移除的阶段
- 2、使驱动程序处于非活动状态
- [3、清除 I/O 队列](#3、清除 I/O 队列)
- 4、分离和释放对象
十二、基类和辅助类层次结构
十三、参考书目
- 1、系统内部
- [2、网站 - 在线资源](#2、网站 - 在线资源)
十四、词汇表
[十五、I/O Kit 系列参考](#十五、I/O Kit 系列参考)
- 1、ADB
- [2、ATA 和 ATAPI](#2、ATA 和 ATAPI)
- 3、Audio
- 4、FireWire
- 5、Graphics
- - [关于 NDRV 兼容性的说明](#关于 NDRV 兼容性的说明)
- 6、HID
- 7、Network
- [8、PC Card](#8、PC Card)
- [9、PCI 和 AGP](#9、PCI 和 AGP)
- 10、SBP-2
- [11、SCSI 并行](#11、SCSI 并行)
- [12、SCSI 架构模型](#12、SCSI 架构模型)
- 13、Serial
- 14、Storage
- - [IOMedia 过滤器方案](#IOMedia 过滤器方案)
  - - 分区方案
  - [IOMedia 属性](#IOMedia 属性)
  - [从应用程序访问 IOMedia](#从应用程序访问 IOMedia)
- 15、USB
- [16、不包含 I/O Kit 系列的设备](#16、不包含 I/O Kit 系列的设备)

一、I/O Kit 基础知识简介

本文档介绍了 I/O Kit 的术语、概念、架构和基本机制。

I/O Kit 是 Apple 用于开发 OS X 设备驱动程序的面向对象框架。

它包含了任何想要为该平台创建设备驱动程序的人所需的基本背景信息。

1、谁应该阅读本文档？

I/O Kit 开发人员通常分为两类，本文档力求对这两类开发人员都有用。

第一种开发人员创建驻留在内核中的设备驱动程序；第二种开发人员使用 I/O Kit 设备接口与硬件通信。

有些章节包含对这两类开发人员都有用的信息，而其他章节包含的信息仅对驻留在内核中的驱动程序的编写者有用。

显然， I/O Kit 基础知识 没有涵盖某些内容。

例如，它没有描述开发工具的使用或特定驱动程序编程接口的使用。

但它确实可以帮助您了解 I/O Kit 的使用方法和原因，使您能够从更具体的文档和示例中获得最大价值。

2、本文档的组织

I/O Kit 基础知识 对 OS X 上的 I/O Kit 和设备驱动程序开发进行了广泛的概念性描述。

它包含以下章节：

什么是 I/O Kit ？
描述 I/O Kit 的特性和优点，并讨论其设计理念和决策。
架构概述
对 I/O Kit 的架构、基本概念和基本机制进行高层描述。
I/O 注册表
描述 I/O 注册表，这是一个捕获活动驱动程序对象之间的客户端/提供者关系的动态数据库。
驱动程序和设备匹配
解释为已注册的提供程序找到最合适的客户端驱动程序的匹配过程。
它还总结了用户空间中为找到合适的设备及其驱动程序所遵循的流程。
基类
描述每个驱动程序对象直接或间接继承的基类。
其中包括对对象构造和处置、驱动程序对象作为 I/O 注册表项以及驱动程序生命周期的讨论。
处理事件
解释工作循环和事件源的架构和用法，I/O Kit 使用它们在受保护的单线程环境中处理中断和 I/O 请求等事件的机制。
管理数据
描述如何使用内存游标、内存描述符和相关对象来处理 I/O 传输。
它还讨论了驱动程序应如何处理硬件约束，例如 DMA 引擎施加的约束。
管理电源
解释 OS X 电源管理的概念并描述驱动程序对其设备进行电源管理的不同方法。
管理设备移除
解释如何响应设备移除（热插拔）。
I/O Kit 系列参考
显示每个系列的类层次结构图，并提供可能与通用 I/O Kit 信息不同的系列特定信息。
基类和辅助类层次结构
为所有不属于特定系列的 I/O Kit 类提供类层次结构图。
文档修订历史
列出对此文档的更改。
参考书目
列出有关 OS X 和相关主题的其他信息来源。
词汇表
定义本文档中使用的关键术语。

3、也可以看看

一旦你吸收了 I/O Kit 基础知识 中的信息，你就可以继续前进并真正创建设备驱动程序。

Apple 提供了几个文档和其他信息来源来帮助你完成这项工作：

IOKit 设备驱动程序设计指南 描述了设计、编码、调试和构建驻留在内核的设备驱动程序所需的一般步骤。
从应用程序访问硬件 讨论了如何使用 I/O Kit 的"设备接口"功能；它还包括通过 BSD 设备文件的串行和存储 I/O 信息。
内核扩展编程主题 包含一系列教程，向您介绍开发工具并指导您完成创建、调试和打包内核扩展和 I/O Kit 驱动程序（一种内核扩展）所需的步骤。
它还包括有关内核扩展其他方面的信息。
内核编程指南 概述了 OS X 内核环境的架构和组件（Mach、BSD、网络、文件系统、I/O Kit）。
所有打算在内核中编程的开发人员（包括设备驱动程序编写者）都应该阅读此文档。
Mac 技术概述 对 OS X 进行了整体介绍，对于新接触该平台的开发人员很有用。

当然，您随时可以浏览 I/O Kit 附带的头文件，它们安装在 Kernel.framework/Headers/iokit（内核驻留）和 IOKit.framework/Headers（设备接口）中。

您还可以在 Xcode 中查看开发者文档。

为此，请从 Xcode 菜单中选择"帮助"，然后单击"显示文档窗口"。

您可以通过两种方式浏览 BSD 手册页以获取有关 BSD 和 POSIX API 的更多信息：您可以在终端窗口中键入man function_name（例如 man gdb），也可以在 OS X 手册页 中查看 HTML 版本。

如果您准备开发一个通用二进制版本的设备驱动程序以在基于 Intel 的 Macintosh 上运行，请首先阅读《通用二进制编程指南，第二版》。

然后，参阅《IOKit 设备驱动程序设计指南》* ，以了解设备驱动程序开发人员特别感兴趣的问题概述。

特定于特定设备类型的相关信息可在硬件和驱动程序文档中列出的文档中找到。

Apple 维护着多个网站，开发人员可以在这些网站上获取有关 OS X 的常规信息和技术信息。

Apple 开发者连接参考库 : http://developer.apple.com/referencelibrary/index.html
包含全面的技术资源集合，包括文档、示例代码和技术说明。
Apple 开发者连接：OS X : http://developer.apple.com/devcenter/macosx
提供 SDK、发行说明、产品说明和新闻以及其他与 OS X 相关的资源和信息。
AppleCare 支持网站 : http://www.apple.com/support
提供了搜索功能，让您可以查找有关 OS X 和其他领域的技术文章、手册、规格和讨论。

二、什么是 I/O Kit ？

I/O Kit 是用于在 OS X 中创建设备驱动程序的系统框架、库、工具和其他资源的集合。

它基于以受限形式的 C++ 实现的面向对象编程模型，省略了不适合在多线程内核中使用的功能。

通过对连接到 OS X 系统的硬件进行建模并抽象特定类别设备的通用功能，I/O Kit 简化了设备驱动程序开发过程。

本章讨论了 I/O Kit（以及用它开发的驱动程序）的固有功能、其设计决策以及 I/O Kit 作为产品时的情况。

它还为那些考虑开发内核软件（如设备驱动程序）的人提供了一些注意事项和指导。

1、在你开始之前

您可能已经为其他平台开发了设备驱动程序 --- 可能是 Mac OS 9、BSD 或其他 UNIX 版本。

阅读本文档时，您会发现 I/O Kit 的方法有多么不同。

虽然为 OS X 编写驱动程序需要新的思维方式和不同的编程方式，但转向这种新方法会让您受益匪浅。

I/O Kit 简化了驱动程序开发并支持多种设备类别。

一旦您掌握了 I/O Kit 的基础知识，您就会发现创建设备驱动程序是一件相对简单且高效的事情。

在你尝试使用 I/O Kit 进行驱动程序开发之前，Apple 强烈建议先决条件。

由于该框架使用面向对象的编程模型，该模型是在有限的子集中实现的C++，了解 C++ 或面向对象概念会有所帮助。

此外，设备驱动程序与应用程序不同，因为它们驻留在内核中，所以必须遵守更严格的规则。

因此，了解内核编程非常有用。

事实上，除非绝对必要，否则不鼓励在内核中编程。

在系统的更高级别上存在许多与硬件和网络通信的替代方案，包括"从内核外部控制设备" 中描述的 I/O Kit 的"设备接口"功能。

有关内核编程替代方案的更多信息，请参阅 "您应该在内核中编程吗？" 。

2、I/O Kit 功能

从一开始，I/O Kit 的基本目标就是适应和增强 OS X 的原生特性和功能，尤其是内核环境的特性和功能。

作为 OS X 的驱动模型，I/O Kit 支持以下功能：

动态和自动设备配置（即插即用）
许多新型设备，包括图形加速和多媒体设备
电源管理（例如"睡眠"模式）
内核对受保护内存的执行------为内核和用户程序提供单独的地址空间
抢占式多任务
对称多处理
不同类型的设备之间共享的通用抽象
增强开发体验------新驱动程序应该易于编写

I/O Kit 通过其新的设备驱动程序模型支持这些内核功能并添加了一些附加功能：

面向对象的框架，实现所有驱动程序和驱动程序类型（系列）之间共享的通用行为
为开发商提供众多住宅
用于处理以下问题的线程、通信和数据管理原语：多处理、任务控制和 I/O 传输
稳健、高效的匹配和加载机制，可完美扩展到所有总线类型
I/O 注册表，一个跟踪实例化对象（例如驱动程序实例）并提供有关它们的信息的数据库
这I/O 目录，系统中所有可用的 I/O Kit 类的数据库
一套设备接口------允许"用户空间"中的应用程序和其他软件与驱动程序进行通信的插件机制
整体表现优异
支持客户端和提供者对象的任意复杂分层

I/O Kit 的面向对象编程模型是在 C++ 的一个受限子集中实现的。

面向对象本身在驱动程序开发中是一个优势，因为它促进了代码的可重用性。

一旦您熟悉了 I/O Kit，您就可以比使用过程模型更快、更有效地编写设备驱动程序。

此外，代码可重用性减少了驱动程序的内存占用；例如，从 Mac OS 9 移植的驱动程序在 OS X 中的大小最多可减少 75%。

3、I/O Kit 的设计原则

OS X 主要是两种操作系统技术的产物：Mac OS 9（及其前身）和 BSD。

鉴于这种血统，人们可能以为 Apple 会采用 Mac OS 9 或 FreeBSD 的设备驱动程序模型。

相反，Apple 选择重新设计该模型。有几个原因促使了这一决定。

首先，无论是 Mac OS 9 驱动模型还是 FreeBSD 驱动模型，都没有提供足够丰富的功能来满足 OS X 的需求。

OS X 内核比其 Mac OS 前身先进得多；它处理内存保护、抢占式多任务、多处理以及 Mac OS 以前版本中不存在的其他功能。

尽管 FreeBSD 能够处理这些功能，但 BSD 模型不提供现代操作系统所期望的其他功能，包括自动配置、驱动程序堆叠、电源管理和设备动态加载。

因此，I/O Kit 背后的主要动机是当前可用的驱动程序模型的不足。

重新设计 I/O 架构必须利用并支持 OS X 的操作系统功能。

为此，I/O Kit 的设计人员决定采用面向对象的编程模型，该模型抽象 OS X 系统的内核功能和硬件，并向操作系统的上层提供此抽象的视图。

此抽象的引人注目的部分是实现 I/O Kit 类中所有设备驱动程序（或设备驱动程序类型）的共同行为。

例如，考虑虚拟内存。

在 Mac OS 9 中，虚拟内存不是操作系统的基本组成部分；它是一个选项。

因此，开发人员在创建驱动程序时必须始终考虑虚拟内存，这会带来一定的复杂性。

相比之下，虚拟内存是 OS X 的固有功能，无法关闭。

由于虚拟内存是一项基本且假定的功能，因此对它的知识已融入系统软件中，驱动程序编写者不必考虑它。

I/O Kit 充当设备驱动程序的基础和协调器。

这与以前的驱动程序模型不同。

在 Mac OS 9 中，所有软件开发工具包 (SDK) 都相互独立，并重复通用功能。

OS X 将 I/O Kit 作为单个驱动程序的一部分提供内核开发工具包 (KDK)；KDK 的所有部分都基于通用基础。

OS X 帮助开发人员充分利用硬件复杂性，而无需他们将软件复杂性编码到每个新设备驱动程序中。

在大多数情况下，他们只需添加使其驱动程序与众不同的特定代码即可。

I/O Kit 设计理念的另一部分是使设计完全开放。

所有 I/O Kit 源代码都作为 Darwin 的一部分提供，而不是为了保护开发人员而隐藏 API。

开发人员可以使用源代码来辅助设计（和调试）新驱动程序。

4、I/O Kit 的局限性

尽管 I/O Kit 支持大多数类型的 OS X 系统不支持所有硬件，但它并不完全支持所有硬件。

其中一类设备是用于成像，其中包括打印机，扫描仪，以及数码相机。

I/O Kit 仅为这些设备提供有限的支持，通过 FireWire 和 USB 系列处理与这些设备的通信。

用户空间中的应用程序或其他程序负责控制这些设备的特定特性（有关详细信息，请参阅从内核外部控制设备）。

如果您的应用程序需要驱动成像设备，则应使用适当的成像软件开发工具包（SDK）。

尽管 I/O Kit 试图表示 OS X 系统中硬件设备和服务之间的层次结构和动态关系，但有些东西很难抽象。

正是在这些抽象的灰色区域（例如当发生分层违规时），驱动程序编写者更加独立。

即使 I/O Kit 表示清晰准确，I/O Kit 系列代码的可重用性也可能受到限制。

所有硬件都可能有自己的怪癖，驱动程序代码必须考虑到这些怪癖。

5、语言选择

苹果考虑了几种 I/O Kit 的编程语言，并选择了C++。

选择 C++ 有几个原因。

C++ 编译器已经很成熟，并且该语言支持系统编程。

此外，已经有一个拥有 C++ 经验的 Macintosh（和 BSD）开发人员大社区。

受限子集不允许使用 C++ 的某些特性，包括

例外
多重继承
模板
运行时类型信息 (RTTI) - I/O Kit 使用其自己的运行时类型系统实现

这些功能被删除是因为它们被认为不适合在多线程内核中使用。

如果您觉得需要这些功能，您应该重新考虑您的设计。

您应该能够使用 I/O Kit 编写您需要的任何驱动程序，并满足这些限制。

在 I/O Kit 驱动程序中使用命名空间

请注意，您可以在 I/O Kit 驱动程序中使用命名空间。

使用命名空间可以帮助您避免名称冲突，并可能使您的代码更易于阅读和维护。

请务必使用反向 DNS 格式作为命名空间名称（例如com.mycompany），以避免潜在的命名空间冲突。

如果您决定在内核 I/O Kit 驱动程序中使用命名空间，请不要在命名空间中声明任何 OSObject 子类，否则您的驱动程序将无法加载。

目前，加载器不支持需要限定的 OSObject 派生类，例如下面显示的类：

c 复制代码

namespace com.mycompany {
    class com.mycompany.driver.myClass : public IOService { // This is not allowed.
        OSDeclareDefaultStructors (com.mycompany.driver.myClass);
    };
};

在 I/O Kit 驱动程序中使用静态构造函数

在 OS X v10.4 中，GCC 4.0 是所有新项目（包括 I/O Kit 驱动程序）的默认编译器。

本节介绍了 GCC 3.3 和 GCC 4.0 之间的特定差异，这些差异可能会影响 OS X v10.3.x 和 OS X v10.4.x 之间内核驱动程序的兼容性。

有关 GCC 3.3（OS X v10.3 中的默认编译器）和 GCC 4.0 之间的差异的更多信息（包括移植指南），请参阅 GCC 移植指南 。

如果您在使用 GCC 3.3 或更早版本编译的 C++ I/O Kit 驱动程序（或其他 KEXT）中的函数内执行静态构造，请注意，使用 GCC 4.0 编译的相同 KEXT 将无法再成功加载。

这是因为 GCC 4.0 对于在内核环境中获取和释放锁的要求更加严格。

如果您在使用 GCC 4.0 编译的 I/O Kit 驱动程序中执行函数内静态构造，则在尝试加载时可能会看到以下错误：

c 复制代码

kld():Undefined symbols:
__cxa_guard_acquire
__cxa_guard_release

这个问题的解决方案很简单：将静态构造函数移至全局命名空间。

例如，假设您的 I/O Kit 驱动程序包含一个函数内静态构造函数，如以下代码所示：

c 复制代码

class com_mycompany_driver_mystaticclass;
void com_mycompany_driver_myclass::myfunction(void)
{
    static com_mycompany_driver_mystaticclass staticclass;
    staticclass.anotherfunction();
}

您可以通过更改此代码来避免函数内静态构造，从而避免加载错误，如下面的代码所示：

c 复制代码

class com_mycompany_driver_mystaticclass;
static com_mycompany_driver_mystaticclasss staticclass;
void com_mycompany_driver_myclass::myfunction(void)
{
    staticclass.anotherfunction();
}

请注意，如果您使用 -fno-threadsafe-statics 编译器选项，通过 GCC 4.0 编译 KEXT，您可能无需更改代码即可避免与函数内静态构造相关的加载错误，但这可能会导致其他问题。

具体来说，除非您可以通过其他方式保证线程安全，否则使用此选项编译 KEXT 可能会破坏您的代码。

6、I/O Kit 的部件

从物理和电子角度来看，I/O Kit 由许多部分组成：框架和库、开发和测试工具以及信息资源（例如示例项目、文档和头文件）。

本节对这些部分进行了分类，并指出了它们的安装位置和访问方式。

框架和库

I/O Kit 基于三个 C++库。它们都打包在框架里，但只有 IOKit.framework 是一个真正的框架。

内核框架主要是为了暴露内核头文件，包括libkern 和 IOKit。

这些"库"的代码实际上内置于内核中；但是，驱动程序（加载时）会像库一样链接到内核。

框架或库	描述和位置
内核/IOKit	用于开发驻留在内核的设备驱动程序的库。头文件位置：`Kernel.framework/Headers/IOKit`
内核/libkern	包含对所有内核软件开发有用的类的库。头文件位置：`Kernel.framework/Headers/libkern`
IOKit	用于开发设备接口的框架。位置：`IOKit.framework`

应用程序和工具

你用一把开发应用程序用于构建、管理、调试、检查和打包设备驱动程序。
表 1-2 列出了驱动程序开发中使用的应用程序；这些应用程序安装在 /Developer/Applications 中。

应用	描述
Xcode	OS X 的主要开发应用程序。
Xcode 可管理项目、提供功能齐全的代码编辑器、根据任意复杂的规则构建项目、提供用于软件配置的用户界面，并充当调试和文档搜索的前端。
I/O 注册表资源管理器	可以图形方式探索内容和结构I/O 注册表。
包装制造商	为安装程序应用程序创建安装包；用于部署内核扩展（包括设备驱动程序）。

表 1-3 描述了使用 I/O Kit 开发设备驱动程序时使用的命令行工具；所有工具都位于/usr/sbin/或/sbin中。

注意： 您可以通过在终端应用程序提供的 shell 中输入命令来查看这些工具的在线文档（在 UNIX 世界中称为手册页）。

该命令是man， man 命令的主要参数是您要查看其文档的工具的名称。

例如，要查看kextload工具的手册页，请在终端中输入以下行：

shell 复制代码

man kextload

工具	描述和位置
`ioreg`	打印 I/O Registry（I/O Registry Explorer 应用程序的命令行版本）的内容。
`kextload`	加载内核扩展（例如设备驱动程序）或生成用于远程调试的静态链接符号文件。
`kextunload`	卸载内核扩展（如果可能的话）。
`kextstat`	打印有关当前加载的驱动程序和其他内核扩展的统计信息。
`iostat`	显示终端、磁盘和 CPU 操作的内核 I/O 统计信息。
`ioclasscount`	显示指定类的实例数。
`ioalloccount`	显示内核中 I/O Kit 对象分配的一些内存统计。
`kextcache`	压缩并存档内核扩展（包括驱动程序），以便它们可以在启动时自动加载到内核中。
`gcc`	Apple 版本的 GNU C++ 编译器；Xcode 会使用适合 I/O Kit 项目的正确标志集自动调用它。
`gdb`	Apple 版本的 GNU 调试器；Xcode 会使用适合 I/O Kit 项目的正确标志集自动调用它。

其他 I/O Kit 资源

I/O Kit"产品"中包含一些信息资源，特别是文档和头文件。

其中一些资源在上一章 "I/O Kit 基础知识简介" 中进行了描述

I/O Kit 是Darwin 开源项目。

Apple 维护着一个网站，您可以在其中找到与 I/O Kit 和 Apple 管理的其他开源项目相关的大量信息。

以下两个位置特别有趣：

开源项目 --- http://developer.apple.com/darwin/projects/
在这里，您可以找到 Darwin 和 Darwin Streaming 项目以及其他项目的链接。
此外，还提供了文档和工具的链接。
邮件列表 --- http://developer.apple.com/darwin/mail.html
该页面提供一些链接，可将您带入 Darwin-Development 和 DarwinOS-Users 邮件列表等。

7、您应该在内核中编程吗？

如果您正在考虑为内核环境编写代码，请仔细考虑。

在内核中编程可能是一项困难且危险的任务。

而且通常有一种方法可以在不触碰内核的情况下完成您想要做的事情。

驻留在内核中的软件往往很昂贵。

内核代码"连线"到物理内存中，因此无法被虚拟内存系统调出。

随着越来越多的代码被放入内核，用户空间进程可用的物理内存越来越少。

因此，分页活动可能会加剧，从而降低系统性能。

内核代码本身也不稳定，比应用程序代码更不稳定。

内核环境是一个单一进程，这意味着没有驱动程序与内核中的其他部分之间应有内存保护。

如果在错误的位置访问内存，整个系统就会陷入瘫痪，成为内核恐慌的受害者。

此外，由于内核代码通常为众多用户空间客户端提供服务，因此代码中的任何低效率都会传播到这些客户端，从而影响整个系统。

最后，编写内核软件确实很麻烦。

需要处理一些在应用程序开发领域未知的微妙问题。

而且内核代码中的错误比用户空间软件中的错误更难发现。

考虑到所有这些，信息很明确。

将尽可能少的代码放入内核符合每个人的最佳利益。

并且任何最终进入内核的代码都应该经过精心打磨和严格测试。

代码何时应驻留在内核中

少数情况需要将驱动程序或扩展加载到内核环境中：

该软件由内核环境本身使用。
用户空间程序将频繁使用该软件。
软件需要直接响应主要中断（由 CPU 的中断控制器传送的中断）。

如果你编写的软件不符合上述任何标准，那么它可能就不属于内核。

如果你的软件是磁盘、网络控制器或键盘的驱动程序，那么它应该驻留在内核中。

如果它是作为文件系统的扩展，它应该驻留在内核中。

另一方面，如果它只是偶尔由单个用户空间程序使用，它应该由该程序加载并驻留在其中。

打印机和扫描仪的驱动程序属于后一类。

内核驻留代码的替代方案

Apple 提供了许多技术，让您可以完成想要做的事情，而无需使用内核。

首先是高级 API，它们为您提供一些硬件级别的访问权限。

例如，Open Transport 是许多网络功能的强大资源，并且Quartz Compositor 使您能够使用图形子系统执行一些相当低级的操作。

第二，同样重要的是，I/O Kit 框架的设备接口技术。

通过插件架构，该技术使您的应用程序能够与内核交互以访问硬件。

此外，借助 I/O Kit 的帮助，您还可以使用 POSIX API 来访问系列，存储，或网络设备。

请参阅从内核外部控制设备以了解设备接口的摘要，并参阅文档 从应用程序访问硬件 以了解该技术的完整讨论。

注意： Objective-C 不提供设备级 I/O 服务。

但是，在 Cocoa 应用程序中，您可以调用 I/O Kit 和 BSD 提供的设备级功能的 C API。

请注意，您可以在OS X Man Pages中查看记录 BSD 和 POSIX 函数和工具的手册页。

三、架构概述

就像任何复杂系统一样，你可以从不同的角度和不同的粒度来看待 I/O Kit 的设计。

本章将向您介绍更重要的I/O Kit 的架构元素和概念领域：

硬件建模、驱动程序对象的分层以及驱动程序系列、驱动程序和核心所扮演的角色
设备驱动程序的运行环境
I/O Kit 注册表和 I/O 目录
驱动程序匹配
I/O Kit 类层次结构
设备接口

请记住，本章是概述，因此对每个主题的讨论都是有意简短的。

后面的章节将更详细地介绍这些主题中的大多数。

对于设备接口，文档 "从应用程序访问硬件" 非常详细地描述了该技术。

1、驱动程序分层

I/O Kit 设计的核心是模块化、分层的运行时架构，它模拟了通过捕获 I/O 连接中涉及的多个部分（硬件和软件）之间的动态关系，可以了解 OS X 系统的硬件。

连接层（包括驱动程序对象和这些对象所属的系列）以提供程序-客户端关系堆叠。

互连服务或设备链始于计算机的逻辑板（以及控制它的驱动程序），通过发现和"匹配"的过程，将连接扩展到控制系统总线（PCI、USB 等）以及连接到这些总线的各个设备和服务的驱动程序对象层。

您可以使用以下方式查看正在运行的 OS X 系统中驱动程序对象的分层I/O Registry Explorer 应用程序，包含在 OS X 的开发者版本中。

开发者版本还包括一个该应用程序的命令行版本：ioreg，您可以在终端窗口中运行它来显示当前的 I/O 注册表信息。

本节介绍 I/O Kit 的分层架构并描述其主要组成元素：系列、驱动程序和核心。

amilies and Drivers

I/O Kit 系列是一个或多个 C++ 类，它们实现特定类型所有设备所共有的软件抽象。

I/O Kit 包含总线协议系列（例如 SCSI 并行、USB 和 FireWire）、存储（磁盘）设备系列、网络服务系列（包括以太网）、人机界面设备系列（例如鼠标、键盘和操纵杆）以及大量其他设备系列。

A驱动程序通过继承成为某个系列的成员；驱动程序的类几乎总是系列中某个类的子类。

作为系列的成员，驱动程序继承了系列所有成员共有的数据结构（实例变量）和行为。

例如，所有 SCSI 控制器都有某些必须执行的操作，例如扫描 SCSI 总线；SCSI Parallel 系列定义并实现了此扫描功能。

因此，您无需在新的 SCSI 控制器驱动程序中包含扫描代码（除非您需要不同的扫描实现）。

大多数 I/O Kit 开发都涉及编写特定的驱动程序类，每个类都从提供驱动程序所需功能的系列中的超类继承。

例如，以太网控制器的驱动程序从 Network 系列中的 IOEthernetController 超类继承。

驱动程序与其自身系列的交互主要涉及实现该系列调用的成员函数。

这些通常是客户端配置和I/O 请求。

某些系列还定义对象和函数供驱动程序使用。

这些对象和函数的具体性质取决于驱动程序所使用的系列。

但是，驱动程序通常与两个家族合作。

除了驱动程序所属的家族之外，驱动程序类还必须与设备家族针对设备所连接的总线或协议发布的节点。

节点（如驱动程序和节点所详细解释的）是定义给定协议的访问点和通信通道的对象。

家族（通常表示总线，如 PCI 或 USB）通过其创建的节点充当驱动程序的提供者。

驱动程序使用节点连接到 I/O 注册表并与其设备通信。

例如，PCI 以太网驱动程序将使用 PCI 家族中的IOPCIDevice节点连接到 PCI 总线，并通过 PCI 总线进行通信。

驱动程序与节点的主要交互涉及在节点所连接的总线上发出请求或命令。

例如，SCSI 设备驱动程序通过节点发出 SCSI 命令块并检查结果。

有关家族的更多信息，特别是家族中超类的性质和组成，请参阅 I/O Kit 家族类

驱动程序和核心

I/O Kit 支持两大类驱动程序对象。

第一种是 nub，即定义访问点和通信通道的对象，通常用于给定协议，例如 PCI、USB 或以太网。

第二种是针对单个设备或服务的特定驱动程序。

特定驱动程序通过 nub 与硬件通信以执行 I/O 操作。

I/O Kit 中的驱动程序和 nub 都必须从 IOService 类继承。

A驱动程序是管理特定硬件的 I/O Kit 对象。

驱动程序以内核扩展的形式编写，通常安装在 Extensions 文件夹中（位于/System/Library/Extensions）。

有关创建和安装内核扩展的更多信息，请参阅 《内核编程指南》 中的 "内核扩展概述"。

当为设备选择驱动程序时，但在该驱动程序被加载到内核（作为内核扩展）后，所有必需的系列（就超类及其依赖项而言）都会被加载，以便为驱动程序及其类型的其他驱动程序提供通用功能。

（当然，如果这些系列已经加载，则此步骤不是必需的。）满足驱动程序的所有要求后，将加载驱动程序并将其实例化为对象。

有关此过程的说明，请参阅 I/O 连接的剖析。

节点是一个 I/O Kit 对象，它代表设备或逻辑服务的通信通道，并调解对设备和服务的访问。

例如，节点可以代表总线、磁盘、磁盘分区、图形适配器或键盘。

将节点视为设备插槽或连接器的软件表示可能会有所帮助。

节点还提供以下服务：仲裁、电源管理和驱动程序匹配（参见 I/O 注册表和 I/O 目录）。

Nubs 充当两个驱动程序之间的桥梁，进而充当两个系列之间的桥梁。

驱动程序作为其客户端与 nub（以及 nub 的系列）通信，并可以通过其系列发布一个 nub，该 nub 查找（通过匹配）由其提供驱动程序。

通常，驱动程序会为其控制的每个设备或服务发布一个 nub；但是，当驱动程序支持特定硬件时，它可以充当自己的 nub。

I/O 连接的剖析

I/O Kit 的分层架构模拟了系统硬件总线和设备之间的连接链，将通用功能集中到驱动程序可以与之交互的类中。

每一层都是其下一层的客户端，也是其上一层的服务提供者。

I/O Kit 系列定义的广泛层分组定义了一般类型的 I/O 提供者（如网络或 PCI 总线设备）的通用功能。

请考虑图 2-1，它说明了网络系列中基于 PCI 的以太网控制器驱动程序的客户端和提供者对象的典型分层。

图 2-1 驱动对象作为客户端和提供者

如该图所示，您的驱动程序通常位于两个系列之间，从上层系列中的类继承并使用下层系列的服务。

在以太网控制器，驱动程序参与 C++ 对象堆栈，其中包含来自网络和 PCI 系列的类的实例：

IONetworkStack（接口管理对象）	将 I/O Kit 对象连接到 BSD 网络设施。
IO以太网接口（小块）	管理与设备无关的数据传输和接收。
控制器驱动程序（驱动程序）	通过 IOPCIDevice 对象操作以太网控制器。此对象继承自名为 IOEthernetController 的网络系列类。
IOPCIDevice（核心）	控制器的匹配点；为控制器提供基本的 PCI 总线交互。
IOPCIBridge (驱动程序)	管理 PCI 总线。（其他对象为 IOPCIBridge 提供服务；它们的具体身份取决于硬件配置。）

另一种查看典型 I/O 连接中驱动程序对象堆栈的方法是从动态角度考虑堆栈。

换句话说，当 OS X 系统发现连接到它的新设备时会发生什么？驱动程序对象堆栈是如何构建的？为此，让我们使用 SCSI 磁盘驱动器的示例；图 2-2 中的创建或发现的一般顺序是从左到右。

图 2-2 SCSI 磁盘驱动程序连接中的驱动程序对象

该图说明了SCSI 磁盘驱动程序，存储系列连接到 PCI 总线。

在建立每个单独的连接时，新创建的驱动程序或 nub 也会添加到 I/O 注册表（在 I/O 注册表和 I/O 目录中描述）。

连接链分为几个步骤：

PCI 总线控制器驱动程序是PCI 系列，发现 PCI 设备并通过创建节点 ( IOPCIDevice) 宣布其存在。
节点识别（匹配）适当的设备驱动程序（在本例中为 SCSI 控制器驱动程序），并请求加载该驱动程序。
加载 SCSI 控制器驱动程序会导致SCSI 并行系列及其所依赖的所有系列也将被加载。
SCSI 控制器驱动程序被赋予对 IOPCIDevice nub 的引用。
SCSI 控制器驱动程序是 PCI 系列的客户端，也是 SCSI 并行系列服务的提供者，它会扫描 SCSI 总线以查找可能是这些服务的客户端的设备。
找到这样的设备（磁盘）后，驱动程序会通过创建一个节点 ( IOSCSIDevice) 来宣布该设备的存在。
节点通过匹配过程找到适合该设备的设备驱动程序（磁盘驱动程序）并请求加载该驱动程序。
加载磁盘驱动程序会导致存储系列及其所依赖的所有系列也被加载。
磁盘驱动程序现在是 SCSI 并行系列的客户端和存储系列的成员。
磁盘驱动程序被赋予对IOSCSIDevice节点的引用。

在许多情况下，应用程序和其他"用户空间"程序可以使用 I/O Kit 的设备接口技术来驱动设备（包括大容量存储设备），从而无需驻留在内核的驱动程序。

有关此插件技术的概述，请参阅从内核外部控制设备。

2、设备驱动程序的运行环境

I/O Kit 提供了运行时环境为驱动程序编写者提供了几个强大的功能，其中包括：

动态分层驱动程序架构，允许随时加载和卸载驱动程序，并延迟保留昂贵的系统资源，直到需要它们为止
用于在常见 I/O 操作期间管理数据的标准设施
一个强大的系统，用于在 I/O 操作期间保护对驱动程序资源的访问，这使得驱动程序编写者不必编写自己的代码来启用和禁用中断并管理对驱动程序私有资源的锁定
访问 libkern C++ 库（I/O Kit 本身基于此库）中的服务，以管理集合、执行原子操作和字节交换值，以便在不同类型的硬件上使用

以下部分总结了每个特征。

运行时功能

I/O Kit 驱动程序可以随时加载和卸载或激活和停用，通过软件发起的事件（例如启动和关闭网络堆栈时）和硬件发起的事件（例如在总线上添加或移除 USB 设备时）。

几乎所有驱动程序都必须在动态变化的系统环境中工作。

I/O Kit 通过定义标准使此过程更容易驱动程序对象的生命周期。
通过实现"通用 I/O Kit 类" 中总结的一小组函数，您的驱动程序可以妥善处理设备和服务的添加和删除，以及电源管理系统引起的变化。

在 OS X 中，几乎所有 I/O 操作都需要相同的准备：

分页虚拟内存转换为物理内存
将内存连线到位，这样在 I/O 操作期间就不会被调出页面
建筑描述要读取或写入的数据缓冲区的分散/聚集列表

I/O Kit 提供了一组实用程序类来帮助驱动程序为 I/O 操作准备内存并构建分散/聚集列表，包括 IOMemoryDescriptor 和 IOMemoryCursor 类。

有关这些工具的更多信息，请参阅管理数据一章

在多线程系统中运行的驱动程序必须能够保护其资源免受可重入或并发访问。

I/O Kit 包含一小组用于此目的的类。

工作循环对象运行一个专用线程并管理用于独占访问数据的门控机制。

其他对象称为事件源，使用门控机制来序列化访问关键资源的函数调用，在调用函数之前关闭工作循环门。

有关工作循环和事件源的更多信息，请参阅处理事件一章

这I/O Kit 本身基于 libkern C++ 库，它提供驱动程序通常需要的服务，包括：

保证原子性的算术和逻辑运算
字节交换值大端字节序和小端格式
常见数据集合（例如字符串、数组和字典）的类

有关 libkern 类的更多信息，请参阅 OS 类以及随 OS X 开发人员包安装的 libkern 参考文档。

内核编程约束

内核代码始终驻留在身体的内存，并且不能由页面调出虚拟内存系统。

这使得内核资源比应用程序资源昂贵得多。

如果出现以下情况，您的驱动程序应该驻留在内核中：

它需要主中断（在这种情况下它必须存在于内核中）
它的主要客户端驻留在内核中；例如，大容量存储驱动程序，因为文件系统堆栈驻留在内核中

例如，磁盘、网络控制器和键盘的驱动程序驻留在内核中。

如果您的驱动程序一次只被一个用户空间程序偶尔使用，则应该由该程序加载并驻留在其中。

扫描仪和打印机等设备的驱动程序驻留在用户空间程序中，使用 I/O Kit 的设备接口机制与设备通信。

有关设备接口的更多信息，请参阅从内核外部控制设备

即使驱动程序驻留在内核中，您也应该尽量减少驻留在内核的代码量以及该代码执行的处理量。

例如，控制中断驱动硬件设备的专用应用程序应该提供一个驱动程序，该驱动程序将服务中断所需的最少代码放入内核中，使数据可供其客户端使用，然后返回。

有关谨慎使用内核编程的其他原因，请参阅您应该在内核中编程吗？

如果您的驱动程序必须驻留在内核中，您应该注意以下问题：

最重要的是，内核是一个单一的程序------没有驱动程序与内核其余部分之间的内存保护。
行为不当的内核驻留驱动程序可能会导致操作系统崩溃或挂起。
一个更微妙的问题是内核中的函数调用堆栈限制为 16 KB。
注意不要在函数中声明较大的局部变量。
只要有可能，就应该预先分配缓冲区并重新使用它们。

驻留在内核的驱动程序可以完全访问内核编程接口。

但是，由于其操作级别较低，驱动程序应该只使用Mach 调用而不是BSD 调用。

目前，BSD 内核代码的许多部分对于多线程或多处理来说并不安全。

无论如何，驱动程序很少需要直接执行 Mach 调用，因为 I/O Kit 为驱动程序所需的大多数内核级功能提供了接口。

3、I/O 注册表和 I/O 目录

这I/O Registry 是一个动态数据库，它记录 OS X 系统上参与硬件连接的驱动程序对象网络，并跟踪这些对象之间的提供者-客户端关系。

设备驱动程序必须记录在 I/O 注册表中才能参与大多数 I/O Kit 服务。

I/O 注册表是 I/O Kit 的重要组成部分，因为它支持操作系统的动态功能，允许用户在正在运行的系统中添加或删除设备（特别是 FireWire 或 USB 设备），并让它们立即可用，而无需重新启动。

添加硬件时，系统会自动查找和加载必要的驱动程序，并更新 I/O 注册表以反映新的设备配置；移除硬件时，会卸载相应的驱动程序并再次更新注册表。

注册表始终驻留在系统内存中，不会存储在磁盘上或在启动之间存档。

I/O Registry 将其数据构造为倒置树。

树中的每个对象都来自父节点，可以有一个或多个子节点；如果它是"叶"节点，则没有子节点。

树中的几乎每个节点都代表一个驱动程序对象：一个 nub 或一个实际驱动程序。

这些对象必须从 IORegistryEntry 类（它是 IOService 的超类，而 IOService 是所有驱动程序类的超类）继承。

IORegistryEntry 对象的主要特征是关联属性的列表。

这些属性反映了驱动程序匹配（请参阅驱动程序匹配）并以其他方式添加有关驱动程序的信息。

注册表中捕获的属性来自每个驱动程序的信息属性列表，该列表是驱动程序 KEXT 中的一个文件，其中包含描述驱动程序的特征、设置和要求的键值对。

另一个动态数据库I/O 目录与 I/O 注册表密切配合。

I/O 目录维护系统上所有可用驱动程序的条目。

当 nub 发现设备时，它会从 I/O 目录中请求该设备系列的所有驱动程序的列表。

您可以使用 I/O Registry Explorer 应用程序和ioreg命令行工具，均包含在 OS X 开发者包中。

您还可以使用 IORegistryEntry 类的成员函数以编程方式探索和操作注册表项的属性。

从应用程序和用户空间中的其他程序，您可以使用 I/O Kit 框架中的 API 在 I/O 注册表中搜索和访问驱动程序信息。

有关 I/O 注册表和 I/O 目录的更多信息，请参阅 "I/O 注册表"一章。

有关 IORegistryEntry 类的更多信息，请参阅 "基类" 一章中的动态驱动程序注册（IORegistryEntry）

4、驱动程序匹配

nubs 的主要功能是提供匹配服务，将驱动程序与设备匹配。

与 Mac OS 8 和 9 不同，驱动程序不会因为安装而自动加载。

在 OS X 中，必须先将驱动程序与现有设备匹配，然后才能加载该驱动程序。

驱动程序匹配是 I/O Kit 的一个过程，其中 nub 在发现特定硬件设备后，搜索最适合该设备的驱动程序。

为了支持驱动程序匹配，每个设备驱动程序都定义了一个或多个个性指定它可以支持的设备类型。

此信息存储在 XML 字典中，该字典定义在驱动程序包中的信息属性列表。

字典值指定驱动程序是否是特定设备的候选驱动程序。

当一个 nub 检测到一个设备时，I/O Kit 会通过三个不同的阶段为该 nub 查找并加载驱动程序，使用减法过程直到找到成功的候选者。

匹配阶段如下：

类别匹配 ------ 消除错误设备类别的驱动程序。
被动匹配 ------ 检查每个剩余驱动程序的特性，了解设备的特定属性，从而消除那些不匹配的驱动程序。
主动匹配 ------ 剩余的驱动程序候选探测设备以验证它们是否可以驱动它。

当找到匹配的驱动程序时，将加载其代码并创建个性中列出的主要类的实例。

此时驱动程序的生命周期开始。

有关详细信息，请参阅 "基类"一章中的驱动程序对象生命周期。

有关Driver personalities和匹配过程的详细讨论，请参阅驱动程序和设备匹配章节

5、I/O Kit 类层次结构

I/O Kit 包含几十个 C++ 类，它本身是libkern C++ 库，可加载的基础内核模块。

综合起来，I/O Kit 和 libkern 似乎构成了一个庞大而复杂的类层次结构。

然而，该层次结构的基本结构相当简单，如图2-3所示。

您可以将扩展的 I/O Kit 类层次结构细分为三大类：

libkern 的类（由于其前缀为"OS"，有时也称为 OS 类）
I/O Kit 基类和辅助类
I/O Kit 系列的类别

有关 libkern 和 I/O Kit 库的二进制文件和头文件安装位置的信息，请参阅框架和库。有关此层次结构中的基类（OSObject、OSMetaClass、IORegistryEntry 和 IOService）的功能和接口的详细信息，请参阅基类

图 2-3 I/O Kit 扩展类层次结构

注意： 附录 "基类和辅助类层次结构" 包含 I/O Kit 基类和辅助类的层次结构图；附录 "I/O Kit 家族参考" 包含大多数 I/O Kit 家族的类层次结构图。

操作系统类

I/O Kit 建立在 libkern C++ 库之上；也就是说，I/O Kit 特定类的根超类是 IORegistryEntry，它继承自 libkern 的 OSObject。

与 I/O Kit 一样，libkern 是用 C++ 的一个子集编写的，适合用于可加载内核模块。

具体来说，libkern C++ 环境不包括 C++ 异常处理和运行时类型信息 (RTTI) 功能。

相反，OS 基类实现了与 RTTI 功能相当的功能，以及其他功能。

扩展层次结构的根源是OSObject 类，与该类密切相关的是 OSMetaClass 类。

所有其他 OS 类都是诸如集合和其他数据容器之类的"辅助"类。

以下总结了这些类所起的作用：

OSMetaClass 实现了一种运行时类型信息（RTTI）机制，实现了一定程度的对象自省，并支持通过类名对从 OSObject 派生的对象进行运行时分配。
OSObject 具有用于引用计数（retain和release）的 API、保留对象的内存管理以及不再需要时自动处置对象的 API。
OSObject 还提供了init和free方法的动态默认实现。
操作系统数据容器是 OSObject 的子类，其实例封装了各种类型的数据值（比如布尔值、数字、字符串）并实现和迭代数组和字典等集合。
操作系统数据容器在名称和行为上与用户空间对应容器 Core Foundation 容器大致相同。
由于操作系统和 Core Foundation 类的特征非常相似，因此系统可以轻松地将 Core Foundation 类型转换为操作系统类型，反之亦然。
例如，当跨越用户内核边界时，CFArray 对象会转换为 OSArray。

OS 类通常适用于为内核编写的所有代码，而不仅仅是设备驱动程序。

例如，实现网络服务或文件系统的内核扩展也可以利用这些类。

OSObject 是内核代码必不可少的通用超类。

首先内核模块（如果要使用 KMOD 引用另一个 KMOD 创建的对象，则这些对象最终必须派生自 OSObject。

大多数 I/O Kit 类都假设传递的对象派生自 OSObject。

如果您要将现有的 C++ 代码移植到 I/O Kit，则无需使用 OS 类。

但如果您决定放弃这些类提供的功能（如引用计数或数据容器），则可能需要自己实现它们。

有关 OSObject 和 OSMetaClass 类的更多信息，请参阅 "基类" 一章中的 libkern 基类

通用 I/O Kit 类

扩展类层次结构的中间组包括 IO Kit 基类------IORegistryEntry 和IOService --- 以及一组用于资源管理、数据管理以及线程和输入控制的辅助类。

这组 I/O Kit 类被指定为"通用"，因为所有设备驱动程序类都可能使用它们。

I/O Kit 层次结构的根类是 IORegistryEntry；它继承自IORegistryEntry 是一个 I/O Kit 对象，可以是 I/O Registry 中的一个节点，并具有一个或多个与之关联的属性表（Driver personalities）。

IORegistryEntry 实现了许多功能：

它通过驱动程序attach和detach入口点管理与注册表的连接
它使用以下方式管理定义Driver Personalities的属性表 OSDictionary 对象
它实现了注册表中的锁定，允许以原子方式对注册表进行更新

IOService 是 IORegistryEntry 的唯一直接子类。

几乎所有 I/O Kit 家族超类都直接或间接地继承自 IOService。

最重要的是，IOService 指定动态运行时环境中设备驱动程序的生命周期。

通过匹配虚拟函数对（例如init/ free、start/stop和open/ close），IOService 定义驱动程序对象如何初始化自身、将自身附加到 I/O 注册表、执行所有必要的分配，然后以正确的顺序反转这些操作的影响。

为了支持其对驱动程序生命周期的管理，IOService 提供匹配服务（例如，协助探测）并根据提供程序的存在来实例化驱动程序。

此外，IOService 还包括可用于各种目的的成员函数，包括：

通知和消息传递
电源管理
设备内存（映射和访问）
设备中断（注册、取消注册、启用、引发等等）

有关 IORegistryEntry 和 IOService 类的更多信息，请参阅 "基类" 一章中的 I/O Kit 基类

大多数 I/O Kit 帮助类都具有几个与设备驱动程序运行时环境相关的函数：

实施工作循环和事件源（中断、计时器和命令）以及相关的锁和队列
实现内存游标和内存描述符来管理 I/O 传输中涉及的数据

有关 I/O Kit 辅助类的更多信息，请参阅处理事件和管理数据章节

I/O Kit 系列类

大多数驱动程序都是 I/O Kit 家族中某个类的子类的实例；反过来，家族类往往是 IOService 的子类。

您的驱动程序类应该是您要编写的驱动程序最合适的家族类的直接子类。

例如，如果您正在编写以太网控制器驱动程序，您的驱动程序类应该是 IOEthernetController 的子类，而不是 IONetworkController（IOEthernetController 的超类）。

I/O Kit 有十几个家族，每个家族都有自己的一组类；这些家族包括以下这些：

ADB
ATA and ATAPI
Audio
FireWire
Graphics
HID (Human Interface Devices)
Network
PC Card
PCI and AGP
SBP-2
SCSI Architectural Model
SCSI Parallel
Serial
Storage
USB

Apple 会在开发过程中添加更多系列。

如果您需要某个设备的系列，但目前尚未如果支持，您可以尝试编写自己的系列类。

但是，如果当前不存在系列，请不要认为需要新的系列。

在许多情况下，IOService 类提供了驱动程序所需的所有服务；此类"无系列"驱动程序可以支持特定于某些供应商的许多设备。

有关系列的更多信息，请参阅 I/O Kit 系列一章和附录I/O Kit 系列参考

6、从内核外部控制设备

OS X 最引人注目的功能之一可能是它在进程的虚拟地址空间之间强制执行的不可侵犯的分离。

除非对共享内存进行费力的安排，否则一个进程无法直接接触映射到另一个进程地址空间的数据。

这种分离通过防止内存破坏程序和类似的麻烦导致进程崩溃，增强了系统的稳定性和可靠性。

更重要的是内核地址空间与所有其他进程地址空间之间的分离，有时（从内核的角度来看）这些进程位于"用户空间"。

如果用户空间中的应用程序或其他程序以某种方式侵犯了内核的地址空间，整个系统就会崩溃。

为了使内核和用户空间之间的这种分离更加严密，用户空间中的程序甚至不能直接调用内核 API。

它们必须进行系统调用才能（间接）访问内核 API。

但是，有时用户空间中的程序需要控制或配置设备，因此需要访问内核中的 I/O Kit 服务。

例如，游戏可能需要设置显示器深度或音量，或者磁盘备份程序可能需要充当磁带驱动器的驱动程序。

其他必须以某种方式与内核交互以驱动硬件的应用程序示例包括运行或解释来自扫描仪、操纵杆和数码相机的数据的应用程序。

为了满足这个要求，I/O Kit 包含两种机制：设备接口和POSIX 设备节点。

通过插件架构和定义良好的接口，设备接口机制使用户空间中的程序能够与内核中适合其希望控制的设备类型的节点进行通信。

通过节点，程序可以访问 I/O Kit 服务和设备本身。

对于存储、串行和网络设备，应用程序可以从 I/O Kit 获取所需的信息，以便使用 POSIX API 访问和控制这些设备。

请记住，有些系列服务 I/O Kit 拒绝将其作为设备接口导出到用户空间；这些服务仅在内核内部可用。

例如 PCI 系列。

出于稳定性和安全性的原因，禁止外部访问 PCI 资源。

附录I/O Kit 系列参考列出了导出设备接口的系列。

本节总结了*从应用程序访问硬件* 中的信息。

请参阅本文档以获取设备接口及其使用方法的完整描述。

设备接口机制

设备接口是内核与用户空间进程之间的插件接口。

该接口符合由以下定义的插件体系结构：核心基础插件服务（CFPlugIn)，而它又与微软的组件对象模型 (COM)。

在 CFPlugIn 模型中，内核充当插件主机，拥有自己的一组定义良好的 I/O Kit 接口，I/O Kit 框架提供一组插件（设备接口）供应用程序使用。

从概念上讲，设备接口跨越了用户空间和内核之间的界限。

它处理谈判，身份验证和类似任务，就像内核驻留驱动程序一样。

在用户空间方面，它通过其导出的编程接口实现与应用程序（或其他程序）的通信。

在内核方面，它通过该系列的驱动程序对象创建的节点实现与相应 I/O Kit 系列的通信。

从内核的角度来看，设备接口似乎是一个驱动程序，被称为"用户客户端。

"从应用程序的角度来看，设备接口是一组可以调用的函数，应用程序可以通过这些函数将数据传递给内核并从内核接收数据。

这是因为，从元素层面上讲，设备接口是指向函数指针表的指针（尽管它也可以包含数据字段）。

一旦应用程序获得设备接口的实例，就可以调用该接口的任何函数。

图 2-4说明了设备接口的体系结构，其中显示了通过设备接口获取 SCSI 硬盘访问权限的应用程序。

最好将此图视为图 2-2的变体，图 2-2 显示了驻留在内核的 SCSI 磁盘驱动程序所建立的一系列驱动程序对象连接。

图 2-4 通过设备接口控制 SCSI 设备的应用程序。

一开始，从 PCI 总线驱动程序到 SCSI 设备节点，会发生相同的一系列操作（设备发现、节点创建、匹配、驱动程序加载）。

但随后，SCSI 设备节点会匹配并加载设备接口作为其驱动程序（而不是驻留在内核的驱动程序）。

在应用程序使用设备接口机制访问设备之前，它必须先找到该设备。

它通过一个称为设备匹配。

在设备匹配中，应用程序创建一个"匹配字典"，指定目标设备的属性，然后调用 I/O Kit 函数并传入该字典。

该函数搜索 I/O Registry 并返回一个或多个匹配的驱动程序对象，然后应用程序可以使用这些对象加载适当的设备接口。

有关此主题的更多信息，请参阅设备匹配

如果您开发的自定义驱动程序不是 I/O Kit 系列中某个类的子类，并且您希望应用程序能够访问该驱动程序，则必须编写自己的设备接口。

在用户空间和内核之间进行通信的任何代码都必须使用以下一个或多个功能：

BSD 系统调用
机房工控机
Mach 共享内存

I/O Kit 主要使用 Mach IPC 和 Mach 共享内存。

相比之下，OS X 的网络和文件系统组件主要使用 BSD 系统调用。

POSIX 设备文件

BSD 是 OS X 内核环境的核心组件，它导出了许多符合 POSIX 标准的编程接口。

这些接口支持通过设备文件与串行、存储和网络设备进行通信。

在任何基于 UNIX 的系统中，例如BSD 中，设备文件是位于/dev代表阻止或字符设备，例如终端、磁盘驱动器或打印机。

如果您知道设备文件的名称（例如 disk0s2或mt0），则您的应用程序可以使用 POSIX 函数（例如open、read、write和close ）来访问和控制相关设备。

I/O Kit 在发现设备时会动态创建/dev 中的设备文件。

因此，设备文件集会不断变化；不同的设备可能在任何时候连接到 /dev 中的设备文件，并且同一设备在不同时间可能具有不同的设备文件名。

因此，您的应用程序无法对设备文件名进行硬编码。

对于特定设备，您必须通过涉及设备匹配的过程从 I/O Kit 获取其设备文件的路径。

获得路径后，您可以使用 POSIX API 访问该设备。

请注意，您可以访问使用用户空间的网络服务BSD 套接字 API。

但是，您通常应该使用套接字仅当碳和Cocoa 环境无法提供您所需的功能。

四、I/O 注册表

这I/O 注册表是一个动态数据库，它描述了一组"实时"对象（nubs 或驱动程序），并跟踪它们之间的提供者-客户端关系。

当从系统中添加或移除硬件时，注册表会立即更新以反映设备的新配置。

作为 I/O Kit 的一个动态部分，注册表不存储在磁盘上或在启动之间存档。

相反，它是在每次系统启动时构建的，并驻留在内存中。

用户空间可以通过以下 API 访问 I/O 注册表：I/O Kit 框架。

这些 API 包括强大的搜索机制，可让您在注册表中搜索具有特定特征的对象。

您还可以使用 OS X 开发人员版本提供的应用程序查看计算机上注册表的当前状态。

本章介绍了 I/O Registry 的体系结构以及 Registry 用于表示对象之间关系的平面。

它还概述了设备匹配并介绍了允许您浏览 Registry 的应用程序。

1、I/O 注册表架构和构造

将 I/O 注册表视为一棵树是最有用的：每个对象都是从父节点衍生的节点，并且具有零个或多个子节点。

注册表几乎在所有方面都遵循树的定义，但少数节点有多个父节点除外。

这种情况的主要示例是 RAID 磁盘控制器，其中多个磁盘被组合在一起以显示为单个卷。

然而，除了特殊情况外，将注册表视为树将有助于您直观地了解它的构建和更新方式。

在启动时，I/O Kit 会注册一个平台专家，特定主板的驱动程序对象，它知道系统正在运行的平台类型。

此节点充当 I/O 注册表树的根。

然后，平台专家节点会为该平台加载正确的驱动程序，该驱动程序将成为根的子节点。

平台驱动程序会发现系统上的总线，并为每个总线注册一个节点。

随着 I/O Kit 将每个节点与其相应的总线驱动程序匹配，以及每个总线驱动程序发现与其相连的设备并将驱动程序与其匹配，树将继续增长。

当发现一个设备时，I/O Kit 会从另一个动态数据库（I/O 目录）请求该设备类类型的所有驱动程序列表。

I/O 注册表维护当前运行系统中活动对象的集合，而I/O 目录维护可用驱动程序的集合。

这是驱动程序匹配的三步流程中的第一步，该流程在驱动程序和设备匹配中进行了描述

课程类型等信息保存在驾驶员的信息属性列表，包含 XML 结构属性信息的文件。

属性列表以键值对字典的形式描述驱动程序的内容、设置和要求。

当读入系统时，此信息将转换为 OS 容器，例如字典、数组和其他类型。

I/O Kit 使用此列表驱动程序匹配；用户应用程序可以在 I/O 注册表中搜索具有特定属性的对象，这个过程称为设备匹配。

您还可以使用 I/O 注册表资源管理器（一个显示注册表的应用程序）查看计算机当前加载的驱动程序的属性列表。

记住 I/O 注册表的树状结构，现在将每个节点想象成一个柱状延伸到第三维。

以平台专家节点为根的二维注册表树现在显示在垂直穿过这些柱状的平面上。

I/O Kit 定义了许多这样的平面（您可以将它们视为一组平行平面在不同的高度切割柱子）。

有关此结构的说明请参见图3-1 。

图 3-1 I/O 注册表中的两个平面

有六个I/O 注册表中定义的平面：

Service
Audio
Power
Device Tree
FireWire
USB

每个平面都通过仅显示存在于该关系中的连接来表达 I/O 注册表中对象之间的不同提供者-客户端关系。

最通用的是服务平面，它按注册表构建期间对象所附加的同一层次结构显示对象。

注册表中的每个对象都是其父级提供的服务的客户端，因此每个对象与注册表树中其祖先的连接在服务平面上都是可见的。

其他平面显示出更具体的关系：

音频平面提供了音频信号链的表示，核心音频框架及其插件用于发现有关系统音频设备之间的音频信号路径的信息。
这电源平面显示 I/O 注册表对象之间的电源相互依赖关系，允许您跟踪从提供商到客户端的电源流，并发现如果特定设备断电，哪些对象可能会受到影响。
这设备树平面代表开放固件设备层次结构。
这FireWire 和每个 USB 平面都代表由这些标准定义的内部层次结构。

记住有关 I/O 注册表中的平面的以下几点非常重要：

所有 I/O 注册表对象都存在于所有平面上，但在任何单个平面上，只有由该平面定义的关系连接的对象才可见。
驱动程序不会附加到任何特定平面上的注册表。
相反，如果驱动程序与其他对象的提供者-客户端关系符合该平面的定义，则驱动程序可以参与该平面的连接。

2、I/O 注册表资源管理器

OS X 的开发者版本提供了一个名为I/O 注册表资源管理器可用于检查计算机上设备的配置。

I/O 注册表资源管理器提供 I/O 注册表树的图形表示。

默认情况下，它显示服务平面，但您可以选择检查任何平面。

命令行等效项，ioreg，在终端窗口中显示树。

此工具的优点是，如果您想要在电子邮件中发送该信息，则可以剪切和粘贴树的各个部分。

您可以在终端应用程序中的 shell 提示符下键入man ioreg，以获取使用 ioreg 的完整描述。

打开 I/O Registry Explorer 后，会出现一个分割窗口，其中 I/O Registry 对象位于右上方，六个平面位于左上方，所选对象的属性列表位于窗口的下半部分。

对象后面带有一个三角形，表示它是父节点。

您可以通过单击父节点并向右拖动滚动条来显示其子节点，从而遍历 I/O Registry 树。

图 3-2 显示了 I/O Registry Explorer 窗口中属性列表的示例。

工具菜单中的命令可帮助您搜索 I/O 注册表并检查其内容：

/Applications/Utilities如果从 Finder 打开了 I/O 注册表资源管理器，"转储注册表字典到输出" 会将 I/O 注册表内容放入控制台日志（可通过中的控制台应用程序查看）。
检查器 以 ASCII 格式显示当前选定对象的属性列表。
在主窗口中选择特定属性会导致其值显示在检查器窗口中。
强制注册表更新会 更新 I/O 注册表资源管理器的 I/O 注册表图片，以反映自您首次打开应用程序以来可能发生的任何更改。
Find 对您输入的字符串执行不区分大小写的搜索，如果成功，则显示字符串出现的路径，并用冒号分隔对象名称。

图 3-2 I/O Registry Explorer 窗口示例

五、驱动程序和设备匹配

在使用设备（或任何服务提供程序）之前，必须先找到该设备的驱动程序并将其加载到内核中。

I/O Kit 定义了一个灵活的三阶段匹配过程，可将候选驱动程序范围缩小到一个或多个驱动程序。

然后加载最终候选驱动程序（如果有多个候选驱动程序，则加载最符合条件的驱动程序），并让其首先有机会管理设备或服务提供程序。

匹配过程利用驱动程序信息属性列表中以 XML 键值对形式定义的匹配字典。

每个匹配字典指定驱动程序的个性，声明其是否适用于特定类型的设备或服务。

本章讨论了Driver personalities和描述它们的匹配语言。

然后，它描述了匹配过程，该过程使用Driver personalities中的信息来识别检测到的设备的最合适驱动程序。

本章还简要讨论了应用程序用于加载设备接口的设备匹配过程。

有关完整详细信息，请参阅 从应用程序访问硬件。

1、Driver Personalities和匹配语言

每个设备驱动程序都被视为可加载内核扩展（KEXT），必须定义一个或多个个性信息指定了它可以支持的设备类型。

此信息存储在 XML 中驱动程序的 KEXT 包中的信息属性列表 ( Info.plist) 中定义的匹配字典。

从这个意义上讲，字典是键值对的集合，其中 XML 标签<key>和</key>包含键。

紧跟在键后面的是包含值的标签；这些标签指示值的数据类型；例如，

xml 复制代码

<integer>74562</integer>

将定义一个整数值。

每个匹配的字典本身都包含在信息属性列表的IOKitPersonalities字典。

个性的字典值指定驱动程序是否是特定设备的候选。

个性中的所有值必须匹配，才能为设备选择驱动程序；换句话说，对这些值执行逻辑 AND。

一些键可能采用空格分隔的值列表，这些值通常以 OR 方式检查。

因此，您可能有一个针对特定 PCI 卡Driver personalities的"型号"键，它采用型号列表，每个型号都标识特定卡供应商支持的型号。

所需的特定键取决于系列。

例如，PCI 卡的驱动程序可以定义一个值，该值将根据 PCI 供应商和设备 ID 寄存器进行检查。

某些系列（例如 PCI 系列）提供了相当复杂的匹配策略。

例如，考虑以下键值对：

c 复制代码

<key>IOPCIMatch</key>
<string>0x00789004&0x00ffffff 0x78009004&0xff00ffff</string>

此表达式用于匹配各种 Adaptec SCSI 卡，由两个复合值组成，每个值都可以是有效匹配。

为了评估这些值，驱动程序系列从 PCI 卡读取 32 位供应商和设备 ID，并使用每个 & 符号右侧的值对其进行屏蔽。

然后将该操作的结果与 & 符号左侧的值进行比较，以确定是否存在匹配。

例 4-1显示了以太网控制器驱动程序的 XML 文件中Driver personalities的部分列表。

例 4-1 以太网控制器 XML 个性部分例

c 复制代码

<key>IOKitPersonalities</key>
    <dict>
        <dict>
            <!-- Each personality has a different name. -->
            <key>Name</key>      <string>PCI Matching</string>
 
            <!-- ... some keys not shown ... -->
 
            <!-- The name of the class IOKit will instantiate when probing. -->
            <key>IOClass</key>   <string>ExampleIntel82558</string>
 
            <!-- IOKit matching properties
              -- All drivers must include the IOProviderClass key, giving
              -- the name of the nub class that they attach to. The provider
              -- class then determines the remaining match keys. A personality
              -- matches if all match keys do; it is possible for a driver
              -- with multiple personalities to be instantiated more than once
              -- if several personalities match.
              -->
            <key>IOProviderClass</key>
                <string>IOPCIDevice</string>
 
            <!-- IOPCIDevice matching uses any of four possible PCI match
              -- criteria. This personality just uses IOPCIMatch to check the
              -- device/vendor ID.
              -->
            <key>IOPCIMatch</key>
                <string>0x12298086</string>
 
            <!-- The initial match score for this personality.-->
            <key>IOProbeScore</key>    <integer>400</integer>
        </dict>
 
        <dict>
            <!-- Can have additional personalities. -->
            <!-- ... (not shown) -->
        </dict>
    </dict>

如例 4-1中所述，每个驱动程序都必须包含一个IOProviderClass键，该键的值用于标识驱动程序所附加到的节点。

在极少数情况下，驱动程序可能会将其声明IOResources为 IOProviderClass 键的值。
IOResources是一个附加到 I/O 注册表根目录的特殊节点，它使资源（如 BSD 内核）在整个系统中可用。

传统上，虚拟设备的驱动程序匹配 IOResources，因为虚拟设备不会发布自己的节点。

这种驱动程序的另一个示例是 HelloIOKit KEXT（如使用 Xcode 创建设备驱动程序中所述），匹配 IOResources，因为它不控制任何硬件。

重要提示： 任何将声明IOResources为 IOProviderClass 键值的驱动程序还必须在其个性中包含IOMatchCategory键和一个私有匹配类别值。

这可以防止驱动程序在IOResources nub 上进行独占匹配，从而阻止其他驱动程序在其上进行匹配。

它还可以防止驱动程序与需要在IOResources 上匹配的所有其他驱动程序竞争。
IOMatchCategory 属性的值应与驱动程序 IOClass 属性的值相同，即驱动程序的类名采用反向 DNS 表示法，使用下划线而不是点，例如 com_MyCompany_driver_MyDriver。

由于驱动程序可以包含多个匹配的字典，每个字典为驱动程序定义不同的个性，因此可以为不同的设备加载相同的驱动程序代码。

出于竞争的目的，I/O Kit 将每个个性视为驱动程序。

如果在任何单个个性中，该系列所需的所有属性都匹配，则驱动程序的代码将被加载并有机会为该设备运行。

由于各种原因，您的驱动程序可以具有多种个性。

可能是因为驱动程序（在 KEXT 中打包）支持多种类型的设备，或者更常见的是，支持同一类型设备的多个版本。

另一个原因可能是驱动程序支持类似的设备，每个设备都通过不同的总线连接到系统；例如，Zip 驱动器可以连接到 USB、FireWire、SCSI、ATAPI 和其他总线。

由于每个设备都连接到不同的 nub 类，因此它具有不同的匹配值。

驱动程序的个性也可以从设备通用到设备特定。

AppleUSBAudio 驱动程序的个性（例 4-2）说明了这一点。

例 4-2 AppleUSBAudio 驱动程序的Driver personalities

xml 复制代码

<key>IOKitPersonalities</key>
    <dict>
        <key>AppleUSBAudioControl</key>
        <dict>
            <key>CFBundleIdentifier</key>
            <string>com.apple.driver.AppleUSBAudio</string>
            <key>IOClass</key>
            <string>AppleUSBAudioDevice</string>
            <key>IOProviderClass</key>
            <string>IOUSBInterface</string>
            <key>bInterfaceClass</key>
            <integer>1</integer>
            <key>bInterfaceSubClass</key>
            <integer>1</integer>
        </dict>
        <key>AppleUSBAudioStream</key>
        <dict>
            <key>CFBundleIdentifier</key>
            <string>com.apple.driver.AppleUSBAudio</string>
            <key>IOClass</key>
            <string>AppleUSBAudioDMAEngine</string>
            <key>IOProviderClass</key>
            <string>IOUSBInterface</string>
            <key>bInterfaceClass</key>
            <integer>1</integer>
            <key>bInterfaceSubClass</key>
            <integer>2</integer>
        </dict>
        <key>AppleUSBTrinityAudioControl</key>
        <dict>
            <key>CFBundleIdentifier</key>
            <string>com.apple.driver.AppleUSBAudio</string>
            <key>IOClass</key>
            <string>AppleUSBTrinityAudioDevice</string>
            <key>IOProviderClass</key>
            <string>IOUSBInterface</string>
            <key>bConfigurationValue</key>
            <integer>1</integer>
            <key>bInterfaceNumber</key>
            <integer>0</integer>
            <key>idProduct</key>
            <integer>4353</integer>
            <key>idVendor</key>
            <integer>1452</integer>
        </dict>
    </dict>

此匹配字典定义了三种个性：AppleUSBAudioControl、AppleUSBAudioStream和AppleUSBTrinityAudioControl。

在匹配检测到的 USB Trinity 音频控制设备时，将选择 AppleUSBTrinityAudioControl；

对于任何其他音频控制设备，通用个性 ( AppleUSBAudioControl) 将匹配。

人格的一个共同特征是探测分数。

探测分数是一个整数，反映驱动程序是否适合驱动特定设备。

驱动程序可能在其个性中有一个初始探测分数值，并且它可能会实现一个probe功能，允许它根据其驱动设备的适用性修改此默认值。

与其他匹配值一样，探测分数特定于每个系列。

这是因为一旦匹配通过类匹配阶段，只有来自同一家族的个性才能竞争。

有关探测分数以及驱动程序在probe函数中执行的操作的更多信息，请参阅设备探测

2、驱动程序匹配和加载

在启动时以及任何时候添加或删除设备时，都会对每个检测到的设备（或其他服务/System/Library/Extensions驱动程序提供者）。

该过程动态地为设备或服务找到最合适的驱动程序。

如"架构概述" 一章中的"驱动程序匹配" 中所述，当总线控制器驱动程序扫描其总线并检测连接到该总线的新设备。

对于每个检测到的设备，控制器驱动程序都会创建一个nub。

然后，I/O Kit 启动匹配过程并从设备获取用于匹配的值（例如，检查 PCI 寄存器）。

一旦为 nub 找到合适的驱动程序，就会注册并加载该驱动程序。

该驱动程序反过来可能会创建自己的 nub（可能通过从其家族继承的行为），这将启动匹配过程以找到合适的驱动程序。

驱动程序匹配

当 nub 检测到设备时，I/O Kit 会使用减法过程，分三个不同阶段为 nub 查找并加载驱动程序。

在每个阶段，会从可能的候选者总池中减去那些不太可能匹配的驱动程序，直到找到成功的候选者。

这匹配过程如下：

在类匹配 步骤中，I/O Kit 通过排除任何与提供程序 服务（即 nub）不匹配的驱动程序来缩小潜在驱动程序列表。
例如，当搜索 USB 驱动程序时，可以排除所有源自 SCSI 类的驱动程序对象。
在被动匹配 步骤中，将检查驱动程序的个性（在驱动程序的 XML 信息属性列表中指定）是否具有特定于提供商系列的属性。
例如，个性可能指定特定的供应商名称。
在主动匹配 步骤中，驱动程序的probe函数会根据与之匹配的 nub 进行调用。
此函数允许驱动程序与设备进行通信并验证它是否确实可以驱动该设备。
驱动程序会返回一个探测分数，以反映其驱动设备的能力。
有关更多信息，请参阅设备探测。在主动匹配过程中，I/O Kit 会加载并探测所有候选驱动程序，然后按从高到低的顺序对它们进行排序探测分数。

然后，I/O Kit 选择探测分数最高的剩余驱动程序并启动它。

如果驱动程序成功启动，则将其添加到I/O Registry 和任何剩余的驱动程序候选都会被丢弃。

如果未成功启动，则启动探测分数第二高的驱动程序，依此类推。

如果可能的候选池中有多个驱动程序，如果两者都声称能够驱动该设备，则更通用的驱动程序通常会输给更具体的驱动程序。

设备探测

在主动匹配阶段，I/O Kit 请求池中剩余的候选驱动程序探测设备，以确定它们是否可以驱动该设备。

I/O Kit 调用在IOService 类，在某些情况下由驱动程序的类重写。

这些函数及其调用顺序是

c 复制代码

init()
attach()
probe()
detach()
free() /* if probe fails */

这些功能构成了驱动程序的第一部分生命周期（有关详细信息，请参阅 "基类" 一章中的"驱动程序对象生命周期"）。

请注意，其中四个函数形成互补对，一个嵌套在另一个中：init和free是一对，attach和detach是另一对。

期间主动匹配，候选驱动程序的代码被加载，并且创建个性中列出的主要类。

调用的第一个函数是init，它相当于libkern类的构造函数。

对于 I/O Kit 驱动程序，此函数将包含所选Driver personalities的匹配属性的 OSDictionary 对象作为其唯一参数。

驱动程序可以使用它来识别它已加载的特定个性，确定要生成什么级别的诊断输出，或以其他方式建立基本操作参数。

I/O Kit 驱动程序通常不会覆盖init函数，而是在稍后阶段执行其初始化。

但是，如果您确实要重写init函数（或驱动程序生命周期的几乎任何其他函数），则必须注意做两件事。

第一是调用超类的函数实现。

何时执行此操作取决于函数；例如，在实现中，您应该首先调用超类的init实现，而在free中，您应该将其作为函数的最后一条语句来调用。

第二条一般规则是，您应该在对中的第二个函数中撤消在第一个函数中所做的操作；因此，如果您出于任何原因在init中分配内存，则应该在free中释放该内存。

接下来，调用attach函数（用detach函数括起来）。
attach 的默认实现通过 I/O 注册表中的注册将驱动程序附加到 nub；默认实现将detach驱动程序与 nub 分离。

驱动程序可以覆盖默认实现，但很少需要这样做。

attach之后，调用 probe 函数。

如果驱动程序的匹配字典与提供者（nub）被动匹配，则I/O工具包总是调用驱动程序的probe函数。

驱动程序可能会选择不实现probe，在这种情况下，会调用 IOService 的默认实现，只会返回此信息。

probe函数将驱动程序的提供程序和指向探测分数的指针作为参数。

探测分数是一个有符号的 32 位整数，初始化为Driver personalities中指定的值（如果未明确初始化，则初始化为零）。

初始探测分数最高的驱动程序将首先开始操作设备。
probe函数的目的是为驱动程序提供检查硬件和修改其个性中指定的默认探测分数的机会。

驱动程序可以检查设备特定的寄存器或尝试某些操作，根据其与所检查设备的匹配程度调高或调低其探测分数。

无论发现什么，每个驱动程序都必须使硬件保持与调用时相同的状态，probe以便下一个驱动程序可以探测硬件的原始状态。

如果探测成功，驱动程序在其probe函数中会返回驱动程序对象 (IOService *)，否则返回零。

返回的对象通常是驱动程序本身，但驱动程序可以返回更适合提供程序的另一个驱动程序。

探测分数是一个输入输出参数，probe可以根据它发现的有关设备的信息进行修改。

驱动程序加载

所有驱动程序探测完设备后，将 attach 探测分数最高的一个，并调用其必须由所有驱动程序实现的启动函数。
start 函数初始化设备硬件并准备运行。

如果驱动程序成功启动，它将返回true；其余候选驱动程序实例将被丢弃，成功启动的驱动程序将继续运行。

如果驱动程序无法初始化硬件，它必须让硬件在 start 调用后保持状态,并返回false。

然后，失败的驱动程序将被分离并丢弃，并且下一个探测分数最高的候选驱动程序将有机会启动。

发生这种情况后的一段时间，所有已加载但当前未使用的驱动程序都将被卸载。

3、设备匹配

需要访问设备的用户应用程序必须首先搜索该设备，然后获取适当的设备接口来与其通信。

此过程称为设备匹配。

与驱动程序匹配不同，设备匹配搜索已加载的驱动程序的 I/O 注册表。

要执行设备匹配，请遵循以下基本步骤：

通过获取 Mach 端口与 I/O Kit 建立连接。
定义一个字典，指定要在 I/O Registry 中搜索的设备类型。
通过在字典中设置其他值可以细化搜索。
例如，可以缩小对 IOMedia 对象的搜索范围以查找所有可弹出的媒体。
您可以通过参考特定于系列的文档或查看 I/O Registry Explorer 应用程序输出中显示的信息属性列表，在设备头文件（例如IOSCSIDevice.h或IOATADevice.h）中找到要匹配的值。
获取注册表中与您的字典匹配的所有对象的列表并选择适当的设备。
通过获取设备接口来访问所选设备。
此步骤在从内核外部控制设备中有更详细的说明

有关设备匹配的完整描述，请参阅文档"从应用程序访问硬件 " 。

六、基类

I/O Kit 是一个面向对象的框架，主要由数十个（如果不是数百个的话）C++ 类组成。

这些类可以根据其在类层次结构中的继承关系进行组织。

与所有类层次结构一样，I/O Kit 可以描绘为一棵倒置的树，无子节点（没有任何子类的类）是树的叶子。

进一步类比，树干上的类，尤其是树根上的类是层次结构中大多数类继承的类。

这些是基类。

图 5-1 显示了 I/O Kit 类层次的总体轮廓以及其中基类的位置。

等级制度。

图 5-1 I/O Kit 类层次结构的基类

如图所示，I/O Kit 特有的基类有 IOService 和 IORegistryEntry；也包括作为基类（通过继承）的是 libkern library OSObject 和（特殊意义上）OSMetaClass。

鉴于这些类的重要性，理解它们的重要性显而易见。

它们不仅提供 I/O Kit 的所有其他类所继承的行为和数据结构。

它们还定义内核和驱动程序对象的行为结构：如何创建和处理对象、如何捕获和显示元类信息、驱动程序对象在动态运行时环境中的行为方式以及如何动态建立驱动程序对象之间的客户机/提供者关系。

如果您使用 I/O Kit 编写设备驱动程序，那么您将不得不在早期并在此后频繁处理代码中的基类，因此熟悉它们是个好主意。

本章还概述了一些通常有用的函数和数据类型。

尽管这些函数和类型不适合讨论基类（因为它们不属于任何类），但它们在各种情况下的实用性使它们几乎与任何基类一样重要。

1、libkern 基类

I/O Kit 建立在libkern C++ 库，它是用适合用于可加载的 C++内核模块。

具体来说，libkern C++ 环境不支持多重继承，模板，C++异常处理功能和运行时类型信息 (RTTI)。

省略了 C++ RTTI 功能，因为它不支持按名称动态分配类，这是加载内核扩展所需的功能。

RTTI 还大量使用异常。

但是，libkern C++ 环境定义了自己的运行时类型系统，它确实支持动态加载。

出于成本和稳定性的原因，内核禁止使用异常。

异常会增加代码的大小，从而消耗宝贵的内核内存，并带来不可预测的延迟。

此外，由于 I/O Kit 代码可能被许多客户端线程调用，因此无法保证异常会被捕获。

在任何内核扩展中使用try、throw或 catch 均不受支持，并且会导致编译错误。

虽然您不能在 I/O Kit 驱动程序中使用异常，但您的驱动程序应始终在适当的情况下检查返回代码。

Apple 强烈建议您将所有内核 C++ 代码（包括设备驱动程序的代码）基于 libkern 基类 OSObject 和 OSMetaClass，并遵守这些类规定的约定（请参阅类型转换、对象自省和类信息）。

完全私有于驱动程序的类不需要基于 OSObject，也不需要遵循这些约定。

但是，此类类与 libkern 类的交互将受到限制。

例如，所有 libkern 集合类都存储从 OSObject 继承的对象。

未从 OSObject 继承的自定义类不能存储在 libkern 集合中，例如 OSDictionary 或 OSArray 对象。

重要提示： 目前，加载器不允许使用任何需要限定的 OSObject 子类，例如嵌套类或在命名空间内声明的类（有关命名空间声明的示例，请参阅语言选择）。

例如，I/O Kit 驱动程序中的以下嵌套类声明将阻止驱动程序加载：

c 复制代码

class com.mycompany.driver.myClass {
    class myNestedClass : public IOService {}; // This is not allowed.
};

对象创建和处置（OSObject）

OSObject 是扩展 I/O Kit 层次结构的根。

它不继承自任何（公共）超类，所有其他 libkern 和 I/O Kit 类（OSMetaClass 除外）都继承自它。

OSObject 实现了支持可加载内核模块所需的动态类型和分配功能。

其虚拟函数和重写运算符定义了如何在内核中创建、保留和处置对象。

OSObject 是一个抽象基类，因此它本身不能被实例化或复制。

对象构造

标准 C++ 构造函数不能在 libkern 中使用，因为这些构造函数使用异常来报告失败；您可能还记得，libkern 选择的受限 C++ 形式排除了异常。

因此 OSObject 类（以及 OSMetaClass 类）的主要目的是重新实现对象构造。

为了构造对象，OSObject 定义了init函数并重写new运算符。
new运算符为对象分配内存并将对象的引用计数设置为 1。

使用new运算符后，客户端必须在新对象上调用init函数来执行使其成为可用对象所需的所有初始化。

如果调用init失败，则客户端必须立即释放该对象。

为了支持 OSObject 的 init和new，OSMetaClass 类实现了与对象构造相关的宏。

这些宏将类绑定到内核的运行时类型工具中，并自动定义充当类的构造函数和析构函数的函数。

有关这些宏和 OSMetaClass 的 RTTI 实现的更多信息，请参阅运行时类型信息 (OSMetaClass)。

OSObject 的子类没有明确实现它们的构造函数，并且析构函数，因为它们本质上是通过 OSMetaClass 宏创建的。

此外，你通常既不调用构造函数和析构函数，也不调用 C++ 的new和delete运算符。

这些函数和运算符保留给动态类型和分配工具使用，它们隐式地为类定义它们。

OSObject 代替它们定义了创建和初始化对象的约定。

但是，子类通常会覆盖init函数以执行特定于该类的初始化。

大多数 libkern 和 I/O Kit 类都定义了一个或多个静态函数来创建实例。

命名约定因类而异，但名称通常是类本身的基本名称（首字母小写），或者是with...名称描述初始化参数的某种形式。

例如，OSArray 定义静态创建函数withCapacity、withObjects和withArray；IOTimerEventSource 定义timerEventSource；IOMemoryCursor 定义withSpecification。

如果类没有静态创建函数，则必须使用并调用代替 C++ 构造函数的new初始化方法，如例 5-2所示

有关需要指定类的构造函数和析构函数的样板代码的概述，请参阅类型转换、对象自省和类信息

对象保留和处置

OSObject 定义一个引用计数和自动释放机制来支持内核扩展的安全卸载。

对于此机制，它使用三个虚拟成员函数retain、release和free ------ 并覆盖delete运算符。

其中，您在代码中应该调用的函数只有retain和release，并且您应该遵循某些约定来规定何时调用它们。

新创建的对象和复制的对象具有 1 的引用计数。

如果您已创建或复制了 libkern 对象并且不需要将其保留在当前上下文之外，则应调用release。

这会减少对象的引用计数。

如果该计数为零，则释放该对象；具体而言，release方法将调用名为 free 的替代析构函数，并最终调用 delete 运算符。

如果您不拥有某个对象（即您没有创建或复制它），并且您想将其保留在当前上下文之外，请调用retain 以增加其引用计数。

如果您没有创建、复制或对某个对象调用retain，则永远不应调用release。

此外，一些返回对象的函数会将所有权传递给调用者，这意味着调用者必须在使用完对象后释放该对象，而其他函数则不需要。

请参阅给定函数的参考文档，以了解您的代码是否需要保留或释放其接收的对象。

切勿显式调用delete运算符来释放对象。

此外，切勿直接调用free运算符来释放对象；但是，您可以（并且在大多数情况下应该）覆盖free函数来释放init函数中分配的内存。

运行时类型信息（OSMetaClass）

尽管 libkern 的 C++ 限制形式排除了本机运行时类型信息（RTTI）设施，OSMetaClass 实现了另一种方法运行时类型化工具确实支持按名称动态分配类。

OSMetaClass 不是真正意义上的基类；没有公共 libkern 或 I/O Kit 类从它继承。

但是，OSMetaClass 提供了对象构造和销毁所必需的 API 和功能。

OSMetaClass 本身是一个抽象类，不能直接构造。

OSMetaClass 为所有基于 libkern 的代码提供的功能包括：

动态跟踪类层次结构的机制
安全装卸内核模块
运行时类型化工具使系统能够跟踪每个 libkern（和 I/O Kit）类当前存在多少个实例，并将每个实例分配给一个内核模块（KMOD）。
类实例的自动构造和解构
用于动态类型转换、类型发现、成员资格评估和类似内省行为的宏和函数
根据类类型的某些指示（包括 C 字符串名称）动态分配 libkern 类实例

在 libkern 的运行时类型工具中，会为加载到内核中的内核模块 (KMOD) 中的每个类创建一个静态元类实例（OSMetaClass 的派生类）。

该实例封装了有关类的名称、大小、超类、内核模块以及该类的当前实例数的信息。

加载内核模块的过程分为两个阶段，第一阶段由成员preModLoad函数发起，第二阶段由postModLoad函数发起。

在preModLoad阶段，OSMetaClass 在单个锁保护线程的上下文中静态构建模块中每个类的元类实例。

在postModLoad阶段，OSMetaClass 将构建的元类对象的继承层次结构链接在一起，将元类实例插入到类的全局寄存器中，并记录每个实例从中派生的内核模块。

有关 postModLoad 和相关函数的更多信息，请参阅 OSMetaClass 参考preModLoad文档。

创建的元类信息存储构成了上面列出的 OSMetaClass 功能的基础。

以下部分将详细探讨这些功能中更重要的部分。

对象构造和动态分配

OSMetaClass 的一个特性是它能够根据类类型的指示分配 libkern 对象。

OSMetaClass 的子类可以通过实现以下代码动态地实现这一点：alloc函数；类类型由 OSMetaClass 子类本身提供。

你也可以通过调用以下函数之一来分配任何 libkern 类的实例allocClassWithName函数，提供适当的类类型标识（OSSymbol、OSString 或 C 字符串）。

新分配的对象作为其唯一的实例变量具有保留计数 1，并且未初始化。

分配后，客户端应立即调用对象的初始化函数（init 或 init变体）。

OSMetaClass 定义了许多运行时类型声明基于 alloc 函数的宏和对象构造宏。

根据类的类型（虚拟或其他），必须将其中一个宏作为类声明和实现中的第一个语句插入：

OSDeclareDefaultStructors
声明类的数据和接口，它们需要运行时类型信息。
按照惯例，此宏应紧跟在类声明中的左括号之后。
OSDeclareAbstractStructors
声明虚拟类的数据和接口，这些数据和接口是运行时类型信息所必需的。
按照惯例，此宏应紧跟类声明中的左括号。
当类具有一个或多个纯虚拟方法时，请使用此宏。
OSDefineMetaClassAndStructors
定义 OSMetaClass 子类以及 OSObject 非抽象子类的主要构造函数和析构函数。
此宏应出现在实现文件的顶部，紧接在特定类的第一个函数实现之前。
OSDefineMetaClassAndAbstractStructors
定义 OSMetaClass 子类以及 OSObject 子类（抽象类）的主要构造函数和析构函数。
此宏应出现在实现文件的顶部，紧接在特定类的第一个函数实现之前。
OSDefineMetaClassAndStructorsWithInit
定义 OSMetaClass 子类以及 OSObject 非抽象子类的主要构造函数和析构函数。
此宏应出现在实现文件的顶部，就在为特定类实现第一个函数之前。
在加载时构造 OSMetaClass 实例后，将调用指定的初始化例程。
OSDefineMetaClassAndAbstractStructorsWithInit
定义 OSMetaClass 子类以及 OSObject 子类（抽象类）的主要构造函数和析构函数。
此宏应出现在实现文件的顶部，紧接在为特定类实现第一个函数之前。
在加载时构造 OSMetaClass 实例后，将调用指定的初始化例程。

有关使用这些宏的更多信息（包括使用示例），请参阅类型转换、对象自省和类信息。

类型转换、对象自检和类信息

OSMetaClass 定义了许多宏和函数，几乎可以在任何情况下使用。

它们可以帮助您安全地从一种类型转换为另一种类型，发现任意对象的类，确定对象是否从给定的超类继承，找出给定类的实例数，并产生其他有用的信息。
表 5-1总结了这些宏和函数。

函数或宏	描述
`OSTypeID`	该宏根据类的名称返回类的类型 ID。
`OSTypeIDInst`	此宏返回给定实例所构建的类的类型 ID。
`OSCheckTypeInst`	该宏检查一个实例是否与另一个实例属于同一类类型。
`OSDynamicCast`	此宏动态地将实例的类类型转换为合适的类。它基本上相当于 RTTI 的`dynamic_cast`。
`isEqualTo`	此函数验证调用的 OSMetaClass 实例（代表一个类）是否与另一个 OSMetaClass 实例相同。默认实现执行浅指针比较。
`metaCast`（多种的）	这组函数确定 OSMetaClass 实例（代表一个类）是否是给定类类型，或者是否从给定类类型继承。类型可以指定为 OSMetaClass、OSSymbol、OSString 或 C 字符串。
`modHasInstance`	返回内核模块是否有任何未完成的实例。通常调用此函数来确定模块是否可以卸载。
`getInstanceCount`	此函数返回接收器所代表的类的实例的数量。
`getSuperClass`	此函数返回接收器的超类。
`getClassName`	此函数返回接收器的名称（作为 C 字符串）。
`getClassSize`	此函数返回接收器所表示的类的大小（以字节为单位）。

在 libkern 中定义 C++ 类

当实现基于 OSObject 的 C++ 类时，你调用一对基于 OSMetaClass 类的宏。

这些宏将您的类绑定到 libkern通过定义元类和定义构造函数和通过元类执行 RTTI 簿记任务的类的析构函数。

第一个宏 OSDeclareDefaultStructors，声明 C++ 构造函数；按照惯例，将此宏作为类声明的第一个元素插入到头文件中。

例如：

c 复制代码

class MyDriver : public IOEthernetController
{
    OSDeclareDefaultStructors(MyDriver);
    /* ... */
};

然后你的类实现使用伴随宏，OSDefineMetaClassAndStructors，定义构造函数和析构函数，以及提供运行时类型信息的元类。
OSDefineMetaClassAndStructors 以驱动程序的名称及其超类的名称作为参数。

它使用这些来生成代码，允许在内核运行时加载和实例化驱动程序类。

例如，MyDriver.cpp可能以这样的方式开始：

c 复制代码

#include "MyDriver.h"
 
// This convention makes it easy to invoke superclass methods.
#define super    IOEthernetController
 
// You cannot use the "super" macro here, however, with the
//  OSDefineMetaClassAndStructors macro.
OSDefineMetaClassAndStructors(MyDriver, IOEthernetController);

super宏的定义允许方便地访问超类方法，而不必每次都输入超类的完整名称。

这是 libkern 和 I/O Kit 类实现的常见习惯用法。

你的类实现了一个初始化方法和free方法。

对于非 I/O Kit 类，初始化方法接受所需的任何参数，可以使用任何名称（尽管通常以开头init），并返回 C++bool值。
free方法始终不接受任何参数并返回void。

驱动程序类的初始化方法应在执行任何其他操作之前调用适当的超类初始化方法，如例 5-1所示。

如果超类返回false，则类的初始化方法应中止，释放所有分配的资源并返回false。

否则，您的类可以执行其初始化并返回true。

当 libkern C++ 运行时系统创建类的实例时，它会将所有成员变量填充为零，因此您无需明确将任何内容初始化为零、false 或 null 值。

例 5-1 实现 init 方法

c 复制代码

bool MyDriver::init(IOPhysicalAddress * paddr)
{
    if (!super::init()) {
        // Perform any required clean-up, then return.
        return false;
    }
    physAddress = paddr;  // Set an instance variable.
    return true;
}

要使用初始化方法创建实例，请编写如下代码：

例 5-2 创建实例并调用其 init 方法

c 复制代码

MyDriver * pDrv = new MyDriver; // This invokes the predefined constructor
                                //  of MyDriver itself
 
if (!pDrv) {
    // Deal with error.
}
 
if (!pDrv->init(memAddress)) {
    // Deal with error.
    pDrv->release();    // Dispose of the driver object.
}

因为这使得创建实例更加麻烦，所以您可能需要以许多内核 C++ 类的方式编写一种便捷方法，例如：

c 复制代码

MyDriver * MyDriver::withAddress(IOPhysicalAddress *paddr)
{
    MyDriver * pDrv = new MyDriver;
 
 
    if (pDrv && !pDrv->init(paddr)) {
        pDrv->release();
        return 0;
    }
    return pDrv;
}

使用这种便捷方法，您可以使用如下代码创建驱动程序的实例：

c 复制代码

MyDriver * pDrv = MyDriver::withAddress(paddr);
 
if (!pDrv) {
    // Deal with error of not being able to create driver object.
}
else {
    // Go on after successful creation of driver object.
}

类的free方法应该释放实例所持有的所有资源，然后调用超类的free方法，如例 5-3所示：

例 5-3 实现 free 函数

c 复制代码

void MyDriver::free(void)
{
    deviceRegisterMap->release();
    super::free();
    return;
}

再次提醒，您的代码绝不应该直接对基于 OSObject 类的对象调用delete 或free或操作符。

始终调用 release 来处理此类对象。

2、I/O Kit 基类

所有基于 I/O Kit 的驱动对象都继承自两个基类IORegistryEntry 和IOService。

这些类中的第二个类 IOService 直接继承自 IORegistryEntry，而所有驱动程序对象最终都继承自 IOService。

IORegistryEntry 类将驱动程序对象定义为 I/O Registry 中的节点，而 IOService 则定义驱动程序对象的生命周期以及实现驱动程序常见的其他行为。

IORegistryEntry 和 IOService 之间紧密的继承关系可能会引发人们的猜测，为什么这些类没有设计成一个类。

原因在于性能。

将 IORegistryEntry 作为 IOService 的超类是一种优化，因为就内存占用而言，IORegistryEntry 对象要轻量得多。

动态驱动程序注册（IORegistryEntry）

IORegistryEntry 对象定义 I/O 注册表中的一个节点（或条目）。

正如I/O 注册表一章所详细解释的那样，I/O 注册表是一个动态数据库，它捕获"实时"驱动程序对象的当前图表，跟踪这些对象之间的客户端/提供商关系，并记录描述其个性的属性。

I/O 注册表在 OS X 的动态功能中起着至关重要的作用；当用户添加或移除硬件时，系统会在驱动程序匹配过程中使用注册表，并立即更新它以反映设备的新配置。

每个 IORegistryEntry 对象都有两个与之关联的字典（即 OSDictionary 的实例）。

一个是该对象的属性表，该对象通常也是一个驱动程序对象。

该属性表是匹配字典指定驱动程序的个性之一。

（有关个性的信息，请参阅 Driver personalities和匹配语言。）IORegistryEntry 对象的另一个字典是平面字典，它指定对象如何连接到注册表中的其他对象。

除了反映驱动程序对象之间的所有客户端/提供者关系外，I/O 注册表还标识这些关系的子集。

注册表树的整体及其子集都称为平面。

每个平面通过仅显示存在于该关系中的连接来表达 I/O 注册表中对象之间的不同提供者/客户端关系。

平面关系通常是依赖链之一。

最通用的平面是服务平面，它显示注册表条目的整个层次结构。

注册表中的每个对象都是其父级提供的服务的客户端，因此每个对象与注册表树中其祖先的连接在服务平面上都是可见的。

除了服务平面之外，还有电源、音频、设备、FireWire 和 USB 平面。

有关平面的更多信息，请参阅 I/O 注册表架构和构造

有可能有一个 IORegistryEntry 对象，但它不是 IOService 对象。

这样的对象可以纯粹用于保存与注册表中的该节点相关的信息。

但是，实际上很少需要这样的对象。

这IORegistryEntry 类包含许多驱动程序对象可能有用的成员函数；这些函数分为几类：

属性表函数允许您设置、获取和删除 IORegistryEntry 对象属性表的属性以及序列化属性表。
一些getProperty函数通过注册表对给定键的属性执行同步、递归搜索。
位置函数允许 IORegistryEntry 对象操纵其在注册表树中的位置。
它可以定位、识别并附加到或分离另一个 IORegistryEntry 对象。
迭代函数使您的代码能够遍历整个注册表树或其一部分，并可选择在遇到的 IORegistryEntry 对象上调用"应用程序"回调函数。

有关详细信息，请参阅 IORegistryEntry 的参考文档。

基本驱动行为 (IOService)

I/O Kit 中的每个驱动程序对象都是一个类的实例，该类最终继承自IOService 类。

IOService 最重要的是通过互补的虚拟函数对来定义驱动程序的动态运行时环境中的生命周期。

它管理匹配和探测过程，实现默认匹配行为，并注册驱动程序和其他服务。

但 IOService 类还提供了许多其他用途的丰富功能，包括：

访问驱动程序的提供程序、客户端、状态和工作循环
发帖通知并向其他驱动程序对象或服务发送消息
管理设备电源
实现用户客户端（设备接口）
访问设备内存
注册并控制中断处理程序

本节首先介绍驱动对象的生命周期以及 IOService 在该生命周期中的作用。

然后总结其他主要的 IOService API。

驱动程序对象生命周期

I/O Kit 驱动程序可以随时加载和卸载，或者激活和停用。

每个驱动程序的生命周期都遵循相同的模式，如标准驱动程序超类 IOService 定义的一组函数中所述。

其中一些函数必须由驱动程序实现；其他函数由 IOService 实现，但可以由驱动程序覆盖以获得额外的灵活性。

图 5-2 驱动对象生命周期函数

图 5-2 显示了驱动程序对象生命周期中调用的函数序列。

括号中的线显示了这些函数如何分组为互补对。

驱动程序对象类可以重写这些函数中的任何一个，但必须确保在其自身实现的适当位置调用超类对该相同函数的实现。

例如，当您重写互补对的打开函数（例如init或）时start，您的版本必须在执行自己的初始化之前调用其超类的相应函数，如例 5-1所示。

当您重写关闭函数（例如free或）时stop，您应该在调用超类中的相应函数之前执行自己的清理工作，如例 5-3所示

驱动程序匹配和加载

第一组函数 init 、attach、probe和detach------在驱动程序匹配过程中被调用，并且加载。

此过程发生在启动时以及添加或删除设备时。

以下段落总结了匹配过程，特别关注所涉及的功能；有关该过程的详细讨论，请参阅驱动程序匹配和加载。

当服务提供程序检测到设备时，匹配过程就会启动。

通常，此提供程序是总线（如 PCI 总线）的控制器驱动程序，它通过扫描总线来检测设备。

然后，提供程序（通常通过其系列）创建并通过调用 IOService 注册任何所需的 nubs函数registerService；这个调用反过来会触发匹配过程。

在 IOService 的安排下，I/O Kit 使用减法过程，分三个不同阶段为 nub 查找并加载驱动程序。

在每个阶段，从可能候选者的总池中减去那些被认为不可能匹配的驱动程序，直到找到成功的候选者。

这些阶段包括：

类匹配 ------ I/O Kit 会消除任何错误提供程序 (nub) 类的驱动程序。
被动匹配 ------ I/O Kit 检查剩余 driver 的性格，了解其 families 特定属性。
主动匹配 ------ IOService 会根据驱动程序所匹配的对象调用其余每个驱动程序的probe函数。
该函数允许驱动程序与设备通信并验证它是否确实可以驱动该设备。
返回的探测分数反映了驱动程序驱动设备的合适程度。

当找到匹配的驱动程序时，就会加载其代码并创建个性中列出的主要类的实例。

在前两个阶段，驱动程序的生命周期函数都不会被调用。

只有在第三阶段的主动匹配中，驱动程序才会被要求探测设备是否适用，调用第一组功能。

无论驱动程序是被加载来驱动设备还是仅仅被要求探测设备，调用的第一个生命周期函数是init，它是 libkern 中类的构造函数的等价物。

对于 I/O Kit 驱动程序，此函数将 OSDictionary 作为其唯一参数，其中包含与 XML 文件中的个性相匹配的属性。

驱动程序可以使用它来确定它被加载的特定个性，确定要生成的诊断输出级别，或以其他方式建立基本操作参数。

但是，I/O Kit 驱动程序通常不会覆盖init函数，而是在稍后的阶段执行初始化，如下所述。

有关init和free函数的更多信息，请参阅对象创建和处置 (OSObject)

在驱动程序对象可以探测或启动之前，必须将其附加到 I/O 注册表中。

为此，nub 调用驱动程序的attach函数，该函数通过 I/O 注册表将驱动程序附加到 nub。

互补函数detach将驱动程序从其 nub 中删除。

IOService 为这两个函数提供了默认实现。

驱动程序可以覆盖它们，但很少需要这样做。

如果正在发生主动匹配，那么 nub 接下来会调用驱动程序对象的探测函数。

探测函数返回一个 IOService。

这通常是驱动程序对象本身，但驱动程序可以返回不同类的实例，例如驱动程序的内核扩展包中包含的专门子类。

IOService 的探测默认实现只是返回 this 指针，而不会改变探测分数。

覆盖探测是可选的；大多数驱动程序从属性匹配中获取了足够的信息，不需要覆盖它。

但是，如果您确实覆盖了探测，则必须确保探测不是破坏性的，而让设备处于发现它的状态。

硬件规范通常定义如何进行非破坏性探测。

driver 的start函数与 probe 的实现一样，应该只执行最低限度的系统资源分配，以验证它是否可以操作硬件。

这种保守的方法会延迟内核资源的消耗，直到真正需要它们为止。

每个系列（例如 PCI、USB 或存储）都定义了一对激活和停用函数，以指示驱动程序应准备为 I/O 请求提供服务，并且不再需要驱动程序的服务。

这两个函数通常命名为open和close。

大多数驱动程序都实现这些函数来分配和释放所有必要的缓冲区和其他结构，为 I/O 处理做准备。

一些系列定义了额外的激活和停用级别。

例如，网络驱动程序在和中执行 open 和 close 的操作很少，而是在enable和disable函数中执行设置和拆卸。

无论具体的激活和停用函数是什么，它们都可以在驱动程序的生命周期内多次调用；无论被激活或停用多少次，驱动程序都应该能够正常工作。

驾驶员身份变更

在驱动程序的生命周期中可以多次调用的另一个函数是message函数。

此函数通知驱动程序重要的系统状态变化，例如当磁盘被强制移除时、当电源管理发生变化（睡眠、唤醒）时或当驱动程序被关闭时。

IOService 对此函数的实现不执行任何操作并返回"不支持"结果代码。

有关 IOService 提供的通知和消息传递功能的更多信息，请参阅通知和消息传递

驱动程序关闭

当驱动程序即将永久关闭时，message函数将以终止方式调用消息（kIOMessageServiceIsTerminated）。

如果驱动程序接受终止，则调用其stop函数。

驱动程序应实现 stop函数来关闭、释放或释放它在其start函数中打开或创建的任何资源，并使硬件保持驱动程序最初发现它的状态。

假设驱动程序实现了激活和停用功能，stop函数中通常没有什么可做的。

驱动程序关闭的最后阶段是调用free，当驱动程序对象的引用计数达到零时，就会发生这种情况。

在此函数中，驱动程序可以处置其在 init函数中创建的任何资源。

供应商匹配

如果你正在实施提供者驱动对象（即 I/O Kit 家族成员的子类），你可能想要重写 IOService 的matchPropertyTable 成员函数。

当 IOService 为驱动程序对象执行匹配时，它会调用此方法，以便提供程序类除了 IOService 提供的通用匹配条件之外，还可以实现自己的特定匹配条件。

提供程序应检查传递的匹配字典，以查看它是否包含该系列理解的匹配属性，如果确实理解，则使用它们与特定驱动程序对象进行匹配。

通知和消息

IOService 为驱动对象相互之间以及与 I/O Kit 之间的通信提供了两种机制：通知和消息传递。

当活动服务或驱动程序发生特定事件且其属性与给定字典匹配时，通知将发送给感兴趣的客户端。

消息更具针对性，并且从提供商到客户端单向流动。

任何提供商都可以向其任何客户端发送消息，以通知其运行时环境中的某些变化。

正如前面在驱动程序对象生命周期中讨论的那样，驱动程序客户端实现了message函数接收并响应来自其提供商的消息。

此功能允许它们适应运行时环境的变化。

这些消息可以通知它们系统状态的变化，例如电源状态的变化、服务暂停或即将终止的服务。

提供商实现messageClient（或messageClients）函数通过调用其客户端的方法来发送消息message。

I/O Kit 定义了一些消息，而其他消息可能由系列定义。

请参阅头文件 Kernel.framework/Headers/IOKit/IOMessage.h，以了解 messageClient 和 messageClients函数可以传递给驱动程序的通用消息。

通知的广播稍微复杂一些。

任何驱动程序对象都可以通过addNotification或installNotification函数安装通知处理程序。

通知处理程序设置为在特定驱动程序对象（由匹配属性的字典标识）经历特定类型的状态变化时调用，例如当驱动程序首次发布、随时匹配或终止时。

每个通知处理程序还会被赋予一个优先级编号，以防同时触发同一类型和同一对象的多个通知。

这如果任何驱动程序对象（其个性与提供的匹配字典相匹配）更改为指定状态，则将调用通知处理程序（IOServiceNotificationHandler类型）。

例如，当服务提供者调用registerServices时，它不仅会启动注册过程，还会向所有对该提供者的发布感兴趣的已注册客户端发送通知。

通知请求由 IONotifier 对象的实例标识，通过该实例可以启用、禁用或删除通知。

驱动程序访问器

为了方便起见，IOService 包括许多访问器成员函数可快速访问驱动程序对象的状态以及与其密切相关的对象。

这些函数返回以下对象或值：

驱动程序的状态（getState），一个位字段，指示驱动程序是否处于非活动状态、已注册、已匹配等状态
驱动程序正在使用的工作循环（getWorkLoop）（有关更多信息，请参阅处理事件）
driver 的主要提供者（getProvider），以及OSIterator 对象用于迭代驱动程序的提供程序（如果有多个）（例如，RAID 设备）
驱动程序的主客户端（getClient），以及用于迭代驱动程序客户端的 OSIterator 对象（如果有多个）

其他 IOService 功能

IOService 集成了对许多类别的设备驱动程序有用的功能（除上述概述之外）。

最值得注意的是，此功能包括以下特性：

用户客户端 。
newUserClient函数创建一个基于 IOUserClient 的连接，用于与非内核客户端进行通信；客户端通过调用I/O Kit 框架的 IOServiceOpen 功能。
设备内存 。
多个 IOService 成员函数可获取、映射和设置分配给内存映射设备的物理内存范围。
这些函数适用于作为 PCI 设备客户端的驱动程序对象。
中断处理 。
IOService 提供用于注册、取消注册、操作和访问中断处理程序的低级函数，这些函数在设备中断的主中断时调用。
这些函数提供了一种安装中断处理程序的机制，该机制不基于工作循环。

七、I/O Kit 系列

在 I/O Kit 中，系列是定义和实现特定类型所有设备所共有的抽象的类的集合。

它们为开发这些系列的成员（提供者）或客户端驱动程序提供编程接口和通用支持代码。

本章描述了一些与 I/O Kit 系列相关的概念：

driver 与 families 的关系
系列作为库，包括库的版本控制和加载
系列的程序结构和命名约定

此外，本章还为那些想要编写自己的 I/O Kit 系列的人提供了一些提示。

有关 Apple 当前提供的 I/O Kit 系列的参考，请参阅附录I/O Kit 系列参考

1、 Drivers 和 Families

I/O Kit 系列是一个实现某些总线协议（例如 PCI 或 USB）或某些通用服务集的库。

但系列提供的支持是通用的。

系列不包含获取硬件的任何细节，因为它无法对其代表的通用层下的特定硬件做出假设。

驱动程序编写者负责编写代码，以在具体和抽象之间架起桥梁------即在硬件和系列定义的抽象之间架起桥梁。

驱动程序必须扩展系列以支持特定硬件或获取特定功能。

以 SCSI 并行系列为例。

SCSI 并行系列封装了定义明确的 SCSI 并行接口 5 规范。

该规范描述的一件事是如何扫描总线和检测设备。

由于这是一个昂贵的操作，许多 SCSI 并行控制器都包含可以缓存有关检测到的设备的信息的固件。

要利用这种缓存优化，您可以设计控制器驱动程序（SCSI 并行系列的成员），以便它覆盖扫描功能以与固件交互。

系列通常执行某些通用任务，例如扫描总线、查询客户端、排队和验证命令、从错误中恢复以及匹配和加载驱动程序。

驱动程序执行以某种方式影响硬件的任务。

继续使用 SCSI 并行系列的示例，作为 SCSI 并行系列的成员，SCSI 并行控制器驱动程序的主要工作是接收来自其系列的 SCSI 命令，在硬件上执行每个命令，并在命令完成时发送通知。

一些 I/O Kit 系列由它们封装的规范明确界定。

其他系列（例如 Audio 系列）则不那么容易定义，因为没有单一规范规定该系列应包含哪些内容。

在这种情况下，Apple 会仔细选择要纳入系列的抽象集，以使其足够灵活和全面。

所有系列都必须宣传其功能，并且由驱动程序堆栈的更高级别来管理这些功能。

驱动程序在与 I/O Kit 系列的关系中既是提供者又是客户端。

作为系列提供者的驱动程序（通过其核心）也是该系列的成员；它应该从系列中描述其导出服务（无论如何增强）的特定类继承。

另一方面，驱动程序是其导入服务（通过系列的核心）的系列的客户端。

例如，SCSI 磁盘驱动程序将从存储系列继承，而不是从 SCSI 并行系列继承，它是后者的客户端（参见 [图 6-1] ）。

USB 鼠标驱动程序将从 HID（人机接口设备）系列继承，并成为 USB 系列的客户端。

PCI 音频卡驱动程序将从音频系列继承，并成为 PCI 系列的客户端。

图 6-1 驱动程序与 I/O Kit 家族的关系

2、 families 就是 library

families 被实现为库打包为内核扩展 (KEXT)。

它们在信息属性列表中指定其定义属性，并安装在 /System/Library/Extensions 中。

从机械上讲，系列与普通驱动程序略有不同。

两个相关特征将系列与驱动程序区分开来。

首先，驱动程序使用 OSBundleLibraries 属性来表达对系列的依赖关系；其次，系列仅作为驱动程序将其列为库的副产品进行加载。

驱动程序将其所依赖的库指定为 OSBundleLibraries字典的元素。

I/O Kit 保证在加载驱动程序并将其与其系列链接之前将这些库加载到内核中。

请注意，库本身使用 OSBundleLibraries属性声明它们所依赖的库（内核扩展和内核本身）。

您可以在 OSBundleLibraries 字典中将库指定为键值对，其中键是库的捆绑标识符 (CFBundleIdentifier)，值是驱动程序兼容的库的最早版本。

所有版本都以'vers'资源样式表示。
例 6-1给出了 AppleUSBAudio 驱动程序信息属性列表中的一个示例。

例 6-1 OSBundleLibraries 属性

xml 复制代码

<key>OSBundleLibraries</key>
    <dict>
        <key>com.apple.iokit.IOAudioFamily</key>
        <string>1.0.0</string>
        <key>com.apple.iokit.IOUSBFamily</key>
        <string>1.8</string>
    </dict>

尽管 I/O Kit 在加载指定这些依赖项的驱动程序之前会加载库，并按照正确的依赖项顺序加载库，但无法保证它加载没有相互依赖关系的库的顺序。

通常，开发人员应该声明其设备驱动程序或任何其他内核扩展的依赖项。

（如果 KEXT 没有可执行文件，则无需声明依赖项。）他们需要声明哪些依赖项取决于需要解析哪些符号。

如果您包含某个系列或其他库的头文件，或者如果头文件间接包含库，则应该声明该依赖项。

如果您不确定是否存在依赖项，请声明它。

库版本控制

为了能够加载并链接到内核，系列或其他库必须使用两个属性声明其兼容性信息：CFBundleVersion和OSBundleCompatibleVersion。
CFBundleVersion属性定义兼容性的前向限制，即当前版本。
OSBundleCompatibleVersion 属性通过标识库的最后一个 CFBundleVersion定义的版本来定义兼容性的向后限制，该版本破坏了与以前版本的二进制兼容性。

每次修订驱动程序或系列时，您都应适当增加 CFBundleVersion 值。

只有当修订使二进制文件与以前的版本不兼容时，您才应重置OSBundleCompatibleVersion值（为当前值CFBundleVersion），例如当您删除函数或其他符号，或更改类以致 vtable 布局发生变化时。

如果您正在编写 I/O Kit 系列，请确保为您的库指定一个 OSBundleCompatibleVersion 属性；否则，驱动程序和其他内核扩展无法声明对它的依赖，因此无法链接到它。

对于驱动程序和系列（以及所有内核扩展），请确保在内核模块，并且此值相当于信息属性列表中的 CFBundleVersion。

您可以通过 Xcode 中的设置来设置可执行文件中的版本MODULE_VERSION，在目标的自定义设置列表中（您可以在目标的构建视图中找到它）。

库加载

这KEXT 管理器充当内核加载器和链接器。

在启动时或每当系统检测到新连接的设备时，I/O Kit 都会启动匹配过程以查找适合设备的驱动程序。

找到这样的驱动程序后，KEXT 管理器的工作就是将驱动程序加载到内核中并将其与所依赖的库链接起来。

但在执行此操作之前，KEXT 管理器必须确保首先加载这些库以及这些库所依赖的所有其他库。

为此，管理器会构建驱动程序所需的所有库和其他内核模块的依赖关系树。

它使用OSBundleLibraries属性的内容构建此树，首先是驱动程序，然后是每个所需库。

在构建依赖关系树之后，KEXT 管理器会检查树中距离驱动程序最远的库是否已加载。

如果这些库中的任何一个尚未加载，管理器将加载它并调用其启动例程（该例程因 KEXT 类型而异）。

然后，它以类似的方式继续依赖关系树 --- 链接、加载和启动 --- 直到所有必需的库都已链接和加载。

有关此过程的说明，请参见图 6-2 。

图 6-2 OSBundleLibraries 和依赖关系树

如果 KEXT 管理器在初始化库时遇到问题，或者找不到具有兼容版本的库（基于的值OSBundleCompatibleVersion），它会停止并（通常）返回失败代码。

已加载的模块会保持加载状态一段时间。

通常，模块不使用时不会立即卸载。

I/O Kit 包含一项功能，可跟踪空闲时间并在空闲一段时间后卸载模块。

重要提示： 明确加载内核扩展的唯一方法是使用kextload命令行实用程序。

3、 families 的程序结构

尽管 I/O Kit 家族彼此之间差异很大，但它们也有一些共同的结构元素。

首先，IOService 是所有 I/O Kit 家族的共同超类；每个家族中至少有一个重要类（可能还有更多）继承自 IOService（有关详细信息，请参阅 I/O Kit 基类）。

每个家族都有一个或多个类向驱动程序提供接口。

典型类别

一个驱动程序系列通常为驱动程序定义两个类：

描述驱动程序家族客户端的 nub 接口的类
驱动程序的超类，是驱动程序家族的成员，因此也是其核心的提供者

换句话说，I/O Kit 家族通常定义一个向上接口和一个向下接口。

这些接口是 I/O 连接中涉及的驱动程序对象分层所必需的。

向上接口（即 nub 接口）向系统的其余部分呈现家族封装的硬件抽象和规则定义。

向下接口为成员驱动程序提供子类化接口。

这些接口共同定义了家族中的向上调用和成员驱动程序应进行的向下调用。

除了这两个类之外，系列通常还定义许多实用类和支持类。

附录I/O Kit 系列参考介绍了其中一些类。

一些系列为特定种类的客户端或成员驱动程序指定子类。

例如，Storage 系列为 nub 对象 (IOBlockStorageDevice) 定义了一个通用块存储类，然后还为某些种类提供了特定的子类：IOCDBlockStorageDevice 和 IODVDBlockStorageDevice。

此外，系列还可以包括设备接口类（作为 IOUserClient 的子类）以及特定于该系列的命令（作为 IOCommand 的子类）。

系列还可以具有各种辅助类和头文件，用于特定于系列的类型定义。

有些系列在对驱动程序的需求不大时，不会为驱动程序提供公共节点或提供程序类。

而且 Apple 并未为所有类型的硬件提供系列。

如果您发现 I/O Kit 没有满足您需求的系列或接口，您可以随时创建直接从 IOService 继承的驱动程序。

如果驱动程序的潜在应用程序很少，则有时需要这种"无系列"驱动程序。

它们必须包含系列中的抽象和功能范围以及驱动程序典型的硬件特定代码。

除了直接从 IOService 继承之外，无系列驱动程序还经常使用 I/O Kit 辅助类，例如 IOWorkLoop、事件源类、IOMemoryCursor 和 IOMemoryDescriptor。

命名和编码约定

通常，Apple 对于系列内类命名的立场是，名称应表明该类代表什么。

通常，此名称由硬件规范决定。

例如，PCI 系列为作为该系列提供者的驱动程序定义了 IOPCIBridge 类。

此名称的原因很简单：PCI 桥（如规范所明确）是 PCI 控制器驱动程序控制的内容。

当系列的类没有明确的命名先例时，I/O Kit 将遵循对于 nub（客户端）类，其命名约定为 IO FamilyName Device，而对于提供程序类，其命名约定为 IO FamilyName Controller。

重要提示： 根据类所代表的内容命名类的一般准则同样适用于驱动程序。

驱动程序应根据其控制的设备命名（但不应有多余的后缀"Driver"）。

如果您正在编写自己的 I/O Kit 系列，Apple 建议您对类遵循相同的命名准则。

此外，还有一些其他通用命名约定需要注意。

每个类、函数、类型等都应有一个前缀，以指示编写软件的供应商。

请确保不要使用 Apple 为自己保留的任何前缀（表 6-1）。

字首	意义
OS, os	libkern 或其他内核服务
IO, io	I/O Kit 或 I/O Kit 系列
MK，mk，mach_	Mach内核
Apple, APPLE, apple, AAPL, aapl, com_apple_	Apple 硬件支持（例如 Apple 提供的驱动程序）

此外，私有的内部符号应带有下划线 _ 前缀，以遵循 Apple 使用的惯例。

请勿从 KEXT 访问这些私有 API。

与驱动程序一样，强烈建议使用反向 DNS 表示法（用下划线代替句点）以避免命名冲突。

4、创建 I/O Kit 系列

有时候，您可能会觉得有必要编写自己的 I/O Kit 系列。

通常，这种情况发生在存在一个标准或协议而该标准或协议没有系列存在，并且您发现基于此协议或标准的设备的驱动程序之间需要互操作性。

一个例子可能是绘图仪和实验室设备的 IEEE488 标准。

如果您决定建立 families ，以下是一些可以帮助您的指导原则：

一开始，一起编写系列和驱动程序代码；暂时不必担心驱动程序和系列之间的功能和接口划分。
只需集中精力提出一个好的面向对象设计，确定哪些对象是必需的以及它们应该具有哪些关系。
在您拥有可运行的驱动程序并解决了特定设备的堆栈问题后，请将系列代码与硬件特定代码分开。
一种可能有助于定位系列通用代码（尤其是对于复杂系列）的方法是，为不同的硬件编写两个或更多驱动程序，然后抽象出通用代码。
定义该系列的 nub 对象对驱动程序来说是什么样子 --- 即您的客户端将看到的 API。
为此，请查看规范并封装重要功能（不必包含很少或从未使用的功能）。
请记住，大多数系列的 nub 功能很少。
它们通常封装寻址和仲裁细节。
为将成为您 families 成员的驾驶员定义超类。
保持系列的分层分离严密。
系列不应包含来自任何其他系列或驱动程序的头文件，也不应定义客户端的超类。

还可能存在需要创建"超家族"的情况：该家族以类似于子类的方式扩展现有家族，但有很大区别；其目标是通用性而不是特异性。

第三方供应商可能希望拥有一个超家族来包含基于不同总线协议的驱动程序的通用代码。

这将消除加载不需要的代码的需要。

例如，鼠标供应商可能有一个能够驱动 USB 和 ADB 鼠标的驱动程序。

如果系统需要 USB 鼠标，您不希望同时加载特定于 ADB 的代码。

因此，供应商可能会编写一个充当服务库的超家族；它将特定于总线协议的代码层分离成子家族，并将剩余的代码放入超家族中。

只会加载特定于当前使用的总线的代码。

八、处理事件

设备驱动程序的工作环境可能是操作系统中最混乱的环境。

许多设备需要一系列命令才能执行单个 I/O 操作。

但是，多个线程可以在任何时间、任何地点进入驱动程序的代码，无论是通过客户端 I/O 请求、硬件中断还是超时事件；在多处理器系统上，线程甚至可以并发运行。

驱动程序必须准备好处理所有这些线程。

这些传入线程（每个线程都有自己的事件）给驱动程序带来了一些问题。

驱动程序需要一种方法来保护其数据结构不被不同的线程访问，因为这种同时访问可能会导致数据损坏甚至更糟。

它需要保证对任何必须完成的单个命令或操作的线程的独占访问，以保持驱动程序数据的完整性，或防止死锁或竞争条件。

在 I/O Kit 中，这种保护由 IOWorkLoop 类及其附带的事件源类提供。

1、工作循环

一个IOWorkLoop对象（或简称为工作循环）主要是一种门控机制，可确保单线程访问硬件使用的数据结构。

对于某些事件上下文，工作循环也是一个线程。

本质上，工作循环是与线程关联的互斥（互斥）锁。

它做几件事：

其门控机制同步事件源之间的动作。
它为事件处理提供了一个可堆叠的环境。
它生成一个专用线程来完成中断控制器传递的间接中断。
此机制将工作循环驱动程序的中断处理序列化，从而防止多个中断同时访问驱动程序数据。

为了正确看待工作循环的作用，首先要考虑它针对哪些事件源而设计。

在 I/O Kit 中，有五大类异步事件：

中断事件---来自设备的间接（二次）中断
计时器事件------计时器定期传送的事件，例如超时
I/O 命令 --- 驱动程序客户端向其提供程序发出的 I/O 请求
电源事件------通常通过调用驱动程序堆栈生成
结构事件------通常涉及 I/O 注册表的事件

I/O Kit 提供了处理这些事件来源：IOInterruptEventSource，IOTimerEventSource，和IOCommandGate。（您可以使用对象提供的机制来处理电源和结构事件IOCommandGate。）

每个事件源类都定义了一种特定于事件类型的机制，用于在工作循环的受保护上下文中调用单个函数。

如果携带事件的线程需要访问驱动程序的关键数据，则必须通过其中一个类的对象来执行此操作。

通常，客户端驱动程序在start函数中设置工作循环、事件源和事件处理程序。

为了避免死锁和竞争条件，访问同一数据的所有代码都应该共享一个工作循环，向其注册其事件源，以便使用单个门控机制。

当然，工作循环可以在不相关的对象之间安全地共享，并且通常由单个驱动程序堆栈中不同级别的对象共享。

工作循环也可以专用于特定驱动程序及其客户端。

有关更多信息，请参阅共享和专用工作循环。

I/O Kit 工作循环机制提供的功能大致类似于 Mac OS 9 的垂直回溯管理器、时间管理器和延迟任务管理器。

工作循环架构

I/O Kit 的工作循环机制可以减轻上下文切换是某些操作系统中常用的底层事件处理模型的副产品。

为了保证事件处理的单线程上下文，此模型在一个线程上完成所有操作。

不幸的是，将工作转移到线程需要在事件承载线程的上下文中进行切换。

更准确地说，当此线程从正在运行的上下文转到非运行的上下文时，必须保存其当前寄存器状态。

当安全线程完成其工作时，将恢复原始线程的状态，并将控制权转移回线程最初引用的函数。

在线程上下文之间来回切换会消耗周期。

对于 I/O 命令和计时器事件，工作循环模型的工作方式截然不同。

在这些情况下，相应事件源的线程只需获取工作循环持有的互斥锁。

在Action例程完成之前，无法处理来自任何其他源的事件当前事件返回。

虽然锁是互斥的，但它并不阻止重入。

此外，您可以在同一个驱动程序堆栈中拥有多个工作循环，这增加了死锁。

然而，工作循环确实避免了自我死锁，因为它们基于递归锁：它们总是检查它们是否是当前拥有锁的线程。

I/O Kit 管理中断事件源的方式确实涉及上下文切换。

中断的完成例程在工作循环的线程上运行，而不是在传递中断的线程上运行。

在这种情况下需要上下文切换，因为中断控制器必须立即将直接（主）中断分发给其他线程来运行完成这些中断的例程。

有关详细信息，请参阅处理中断。

有两个因素影响工作循环查询其事件源以获取工作。

线程的相对优先级是主要决定因素，其中计时器具有最高优先级。

客户端线程可以修改其自己的优先级，从而加快 I/O 请求的交付（但这可能不会影响它们的处理速度，因为 I/O 请求通常按 FIFO 顺序排队）。

对于中断事件源，它们也具有相对较高的优先级，将它们添加到工作循环的顺序决定了查询它们的顺序。

有关更多详细信息，请参阅处理中断。

无论事件源和机制如何，工作循环主要用于一件事：运行完成或事件源指定的Action例程。

它保证处理事件的例程是任何给定时间唯一运行的例程。

工作循环的这个方面提出了一个设计要点。

当线程运行代码来处理事件时，其他事件可以异步传递到它们的事件源，但直到处理程序返回后才能处理它们。

因此，事件处理程序不应尝试完成大量工作或执行任何可能阻塞的 操作（即等待其他进程完成），例如分配内存或其他资源。

相反，如果可能的话，它们应该将工作排队或以其他方式推迟到以后处理。

共享和专用工作循环

所有 I/O Kit 服务都可以轻松共享其提供者的工作循环。

驱动程序注册表的基座（代表计算机的逻辑板）始终包含工作循环，因此即使驱动程序本身不创建工作循环，也可以确保它具有工作循环。

驱动程序需要做的就是调用 IOService 的 getWorkLoop 函数来访问其提供者的工作循环。

这样，整个驱动程序对象堆栈或此类对象的子集可以共享一个工作循环。

图 7-1 显示了多个驱动程序对象共享的工作循环如何使用事件源来管理对其门控机制的访问。

图 7-1 共享工作循环的驱动对象

大多数驱动程序不会创建自己的工作循环。

如果硬件不直接在驱动程序中引发中断，或者驱动程序中很少发生中断，则不需要自己的工作循环。

但是，一个驱动程序直接中断（即直接与中断控制器交互的中断）应该创建自己的专用工作循环此类驱动程序的示例包括 PCI 控制器驱动程序（或任何具有提供程序类的类似驱动程序）IOPCIDevice) 和 RAID 控制器驱动程序。

然而，即使这些工作循环也可能由驱动程序的客户端共享，因此重要的是要意识到，无论哪种情况，驱动程序都不能假设它独占了工作循环的使用权。

这意味着驱动程序很少应该启用或禁用其工作循环上的所有事件，因为这样做可能会影响使用工作循环的其他 I/O Kit 服务。

如果驱动程序处理中断或出于其他原因需要自己的工作循环，则应重写 IOService getWorkLoop 函数以创建专用的工作循环，仅供驱动程序及其客户端使用。

如果getWorkLoop没有被重写，驱动程序对象将在其堆栈中获取下一个工作循环。

获取工作循环的示例

要为客户端驱动程序获取工作循环，您通常应该使用提供程序的工作循环，或者在必要时创建自己的工作循环。

要获取提供程序的工作循环，您只需调用 IOService getWorkLoop 函数并保留返回的对象。

获取工作循环后，您应该立即创建事件源并将其添加到工作循环中（确保已启用它们）。

要为您的驱动程序创建专用的工作循环，请重写getWorkLoop函数。
例 7-1 说明了 getWorkLoop 的线程安全的实现，它可以延迟且安全地创建工作循环。

例 7-1 创建专用工作循环

c 复制代码

protected:
    IOWorkLoop *cntrlSync;/* Controllers Synchronizing context */
// ...
IOWorkLoop * AppleDeviceDriver::getWorkLoop()
{
    // Do we have a work loop already?, if so return it NOW.
    if ((vm_address_t) cntrlSync >> 1)
        return cntrlSync;
 
    if (OSCompareAndSwap(0, 1, (UInt32 *) &cntrlSync)) {
        // Construct the workloop and set the cntrlSync variable
        // to whatever the result is and return
        cntrlSync = IOWorkLoop::workLoop();
    }
    else while ((IOWorkLoop *) cntrlSync == (IOWorkLoop *) 1)
        // Spin around the cntrlSync variable until the
        // initialization finishes.
        thread_block(0);
 
    return cntrlSync;
}

此代码首先检查是否cntrlSync是有效的内存地址；如果是，则工作循环已存在，因此代码将返回该地址。

然后，它测试是否有其他线程试图通过原子方式比较并将控制器同步器变量从 0 交换为 1（1 不能是工作循环的有效地址）来创建工作循环。

如果没有发生交换，则其他线程正在初始化工作循环，因此cntrlSync函数将等待变量不再为 1。

如果发生交换，则不存在工作循环，也没有其他线程正在创建工作循环。

在这种情况下，该函数将创建并返回工作循环，这将解除可能正在等待的任何其他线程的阻塞。

就像获取共享工作循环时一样，在 start 调用getWorkLoop 来获取工作循环对象（然后保留它）。

创建并初始化工作循环后，必须创建事件源并将其添加到其中。

有关 I/O Kit 中事件源的更多信息，请参阅以下部分。

2、事件源

工作循环可以添加任意数量的事件源。

事件源是与设备驱动程序可以处理的事件类型相对应的对象；目前有硬件中断、计时器事件和 I/O 命令的事件源。

I/O Kit 为这些事件类型中的每一个定义了一个类：IOInterruptEventSource，IOTimerEventSource，和 IOCommandGate分别。

这些类中的每一个都直接从抽象类 IOEventSource 继承。

事件源对象充当来自特定事件源的事件的队列，并在工作循环上下文要求它们工作时将这些事件移交给工作循环上下文。

创建事件源对象时，您可以指定回调函数（也称为"动作"函数）将被调用来处理事件。

与 Cocoa 环境的目标/动作机制类似，I/O Kit 将事件的目标（通常是驱动程序对象）和要执行的动作作为实例变量存储在事件源中。

处理程序的签名必须符合Action在事件源类的头文件中声明的原型。

根据需要，工作循环依次询问其每个事件源（通过调用它们的checkForWork函数）来处理事件。

如果事件源有排队事件，工作循环将在其自己的受保护上下文中运行该事件的处理程序代码。

请注意，当您向工作循环注册事件源时，事件源会获得工作循环的信号信号量，事件源会使用该信号量来唤醒工作循环。

（有关工作循环如何休眠和唤醒的更多信息，请参阅 IOWorkLoop 文档中的 threadMain 函数。）

客户端驱动程序在其激活阶段（通常是start函数）创建所需的事件源并将其添加到其工作循环中。

驱动程序还必须为每个事件源实现一个事件处理程序，确保函数的签名符合为Action事件源类定义的函数原型。

出于性能原因，事件处理程序应避免执行任何可能阻塞的操作（例如分配内存）并推迟处理大量数据。

有关事件优先级和延迟工作的更多信息，请参阅工作循环事件处理程序。

对于每种类型的事件源，将事件源添加到工作循环的过程都类似。

它涉及四个简单的步骤：

获取你的工作循环。
创建事件源对象。
将对象添加到工作循环中。
启用事件源。

处理事件源也有一个常见的程序模式：

禁用事件源。
将其从工作循环中移除。
释放事件源。

以下各节讨论了每个事件源的细节并给出了每种事件源的具体示例。

处理中断

中断通常是驱动程序处理的最重要的事件类型。

它们是连接到计算机的设备通知操作系统已发生异步操作并因此具有一些数据的方式。

例如，当用户移动鼠标或将 Zip 驱动器插入 USB 端口时，会产生硬件中断，受影响的驱动程序会收到此事件的通知。

本节讨论 I/O Kit 中的中断处理，特别关注IOInterruptEventSource及其子类的对象所起的作用。

I/O Kit 中的中断处理

I/O Kit 的中断处理模型不符合标准 UNIX 模型。

I/O Kit 驱动程序几乎总是在间接中断环境中工作，而不是像 UNIX 模型那样处理直接中断。

间接中断的限制较少，允许Mach 调度程序完成其工作。

（间接中断有时称为二次中断和直接中断主中断。

两种中断类型的差异与处理中断的环境有关。

两种类型的事件会触发中断：

基于命令的事件，例如传入的网络数据包和存储介质的读取
异步事件，例如键盘按下

发生中断时，会设置特定的中断线，一旦被中断的线程完成当前指令，控制就会分支到向平台专家注册的中断控制器。

当中断控制器接收到中断时，其线程将成为直接（主）中断的线程。

系统中通常一次只有一个直接中断，并且直接中断上下文在系统中具有最高优先级。

以下列表指示系统中线程的相对优先级：

直接中断
计时器和页出
实时（多媒体）
间接中断（驱动程序）
窗口管理器
用户线程（包括 I/O 请求）

由于直接中断上下文具有极高的优先级，因此其设计职责是尽快将中断移交给优先级较低的线程。

中断控制器必须解码中断发生的原因，将其分配给适当的驱动程序对象，然后返回。

在直接中断模型中，目标驱动程序假定直接中断的上下文。

它必须在这个最高优先级的上下文中处理中断。

直接中断的问题在于，它们既不能降低优先级，也不能被抢占。

在当前中断被处理之前，所有其他中断实际上都被禁用。

在 OS X 多处理环境中，直接中断尤其不能很好地扩展。

对于间接中断，中断控制器将其从中断线读取的中断分派到目标驱动程序的相应中断事件源对象，从而有效地使其在驱动程序的工作循环线程上进行调度。

然后在工作循环线程上运行由事件源定义的完成（或Action）例程来处理中断。工作循环线程的优先级虽然与大多数客户端线程相比很高，但低于承载直接中断的线程。

因此，在工作循环线程中运行的完成例程可能会被另一个直接中断抢占。

I/O Kit 并不禁止访问直接中断上下文，事实上它为此提供了一个单独的编程接口（请参阅使用没有工作循环的中断处理程序）。

但是，强烈不建议使用直接中断。

工作循环可以有多个IOInterruptEventSource附加到它的对象。

这些对象添加到工作循环的顺序（通过IOWorkLoop 的 addEventSource 函数）决定了处理不同来源的中断的大致顺序。