e1000e网卡驱动分析—网卡驱动的体系结构

在硬件上电初始化时，BIOS统一检查所有的PCI设备，并为每个设备分配一个物理地址，该地址通过BIOS获得并写到设备的配置空间内，CPU不能直接访问，驱动程序可以将这部分配置空间通过ioremap映射到普通内存供CPU访问。

当操作系统初始化时，其为每个PCI设备分配了一个pci_dev结构，并将前面分配的物理地址写到pci_dev的resource字段中。在驱动程序中，可以通过读取这个字段得到设备的配置空间地址，由函数pci_resource_start()以及pci_resource_len()获得配置空间的起始地址和大小，再通过ioremap映射到内存中，供CPU访问，来控制该设备。

e1000e网卡驱动加载时，显而易见的是调用module_init(e1000_init_module)宏，然后调用e1000_init_module()函数，该函数又会进一步的调用pci_register_driver()函数。

pci_register_driver()函数以一个pci_driver的结构作为入参，该结构定义了PCI设备相关的操作函数，如probe、shutdown、remove等，最主要的是定义了id_table。我们知道，网卡设备也是一个PCI设备，而系统所有PCI设备的id_table在系统启动阶段就已经分配，这里的主要目的是用pci_driver结构的id_table和所有PCI设备的id_table比较，找到匹配项，然后取出该PCI设备的pci_dev结构，最后调用probe方法。

/* PCI Device API Driver */ static struct pci_driver e1000_driver = {          .name     = e1000e_driver_name,          .id_table = e1000_pci_tbl,          .probe    = e1000_probe,          .remove   = __devexit_p(e1000_remove), #ifdef CONFIG_PM          .driver.pm = &e1000_pm_ops, #endif          .shutdown = e1000_shutdown,          .err_handler = &e1000_err_handler };

 

在介绍具体的代码前，先介绍下驱动相关的三个数据结构：pci_dev、net_device以及e1000_adapter。这三个数据结构实现了硬件到软件驱动的过渡，要读懂网卡驱动，必须弄清楚这三个结构的关系。

pci_dev结构是在启动阶段保留下来的，体现了PCI设备所有应有的规范。net_device结构，是驱动层的网卡操作结构。这两个结构都表示网卡设备，只是体现的角度不一样，net_device是对特定适配器的抽象，其为上层协议提供了统一的结构，网卡驱动则基于特定的适配器实现了这一抽象。网卡驱动实际操作的是特定的适配器，是由硬件相关的adapter即该驱动中的e1000_adapter所表示的结构体，adapter体现了大部分与硬件相关的特性，网卡驱动除了直接对pci_dev结构操作外，其他队网卡设备的操作基本都是对adapter结构的操作。adapter结构体现了net_device与pci_dev的关联，也实现了网络设备的适配器无关性。

上图中，描述了这三个数据结果的关系。pci_dev结构体现了网卡的配置空间和I/O内存区域，net_device结构则向内核同了操作网卡的抽象接口。e1000_adapter结构除了体现相应的硬件无关性外，还管理了发送与接受数据包的相应缓冲区，网卡的物理地址空间映射后的虚拟地址也在改结构中保存。e1000_adapter结构中的e1000_hw结构主要保存网卡的硬件参数，其值就是通过读取pci_dev的结构获取出来的。

举个例子来说，用户态的收发包驱动netmap，在实现是就继承了网卡驱动中的e1000_adapter和net_device结构，来操作硬件、收发队列以及向上提供接口。