我們結束 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);

};

這個結構定義在 并且被 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 數據結構. 它定義于 和負責任 何可能的跨不同基于 Alpha 的計算機的改變.

[40] 一些體系也顯示 PCI 域信息在 /proc/pci 和 /proc/bus/pci 文件.

[41] 實際上, 那個配置不限定在系統啟動時; 可熱插拔的設備, 例如, 在啟動時不可用并且

相反在之后出現. 這里的要點是設備啟動必須不改變 I/O 或者內存區的地址.

[42]

你將在設備自己的硬件手冊里發現它的 ID. 在文件 pci.ids 中包含一個列表, 這個文 件是 pciutils 軟件包和內核代碼的一部分; 它不假裝是完整的, 只是列出最知名的供應 商和設備. 這個文件的內核版本將來不會被包含在內核系列中.

總結

以上是生活随笔為你收集整理的linux 硬件抽象,Linux 内核硬件抽象的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。