我们结束 PCI 的讨论, 通过快速看一下系统如何处理在市场上的多种 PCI 控制器. 这只 是一个信息性的小节, 打算来展示给好奇的读者, 内核的面向对象分布如何向下扩展到最 低层.
用来实现硬件抽象的机制是通常的包含方法的结构. 它是一个很强功能的技术, 只添加最 小的解引用一个指针的开销到正常的函数调用开销当中. 在 PCI 管理的情况下, 唯一的 硬件相关的操作是读和写配置寄存器的那些, 因为在 PCI 世界中所有其他的都通过直接 读和写 I/O 和内存地址空间来完成, 并且那些是在 CPU 的直接控制之下.
因此, 配置寄存器存取的相关的结构只包含 2 个成员:
struct pci_ops
{
int (*read)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 *val); int (*write)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 val);
};
这个结构定义在 <linux/pci.h> 并且被 drivers/pci/pci.c 使用, 这里定义了实际的公 共函数.
作用于 PCI 配置空间的这 2 个函数有更大的开销, 比解引用一个指针; 由于代码的面向 对象特性, 它们使用层叠指针, 但是操作中开销不是一个问题, 这些操作很少被进行并且 从不处于速度-关键的路径中. pci_read_config_byte(dev, where, val)的实际实现, 例 如, 扩展为:
dev->bus->ops->read(bus, devfn, where, 8, val);
系统中各种 PCI 总线在系统启动时被探测, 并且此时 struct pci_bus 项被创建并且和 它们的特性所关联, 包括 ops 字节.
通过"硬件操作"数据结构来实现硬件抽象在 Linux 内核中是典型的. 一个重要的例子是 struct alpha_machine_vector 数据结构. 它定义于 <asm-alpha/machvec.h> 和负责任 何可能的跨不同基于 Alpha 的计算机的改变.
[40] 一些体系也显示 PCI 域信息在 /proc/pci 和 /proc/bus/pci 文件.
[41] 实际上, 那个配置不限定在系统启动时; 可热插拔的设备, 例如, 在启动时不可用并且 相反在之后出现. 这里的要点是设备启动必须不改变 I/O 或者内存区的地址.
[42] 你将在设备自己的硬件手册里发现它的 ID. 在文件 pci.ids 中包含一个列表, 这个文 件是 pciutils 软件包和内核代码的一部分; 它不假装是完整的, 只是列出最知名的供应 商和设备. 这个文件的内核版本将来不会被包含在内核系列中.