这周又没看书。。。
由于最近要做些网络方面的优化，就又学习了下网络驱动模型。
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, // 驱动所能操纵的设备id列表
.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结构，来操作硬件、收发队列以及向上提供接口。
网友评论