本文介绍基于Realtek 8139芯片PCI接口的网卡驱动程序。我选择了Realtek芯片有两个原因:首先,Realtek提供免费的芯片技术手册; 第二,芯片相当便宜。
本文介绍的驱动程序是最基本的,它只有发送和接收数据包功能,和做一些简单的统计。对于一个全面和专业级的驱动程序,请参阅Linux源码。
本文代码是基于Linux2.4.18上测试的,建议编译一个内核,此内核没有任何形式RealTek8139驱动程序,以避免有莫名的BUG。最后,你将网卡插入PCI插槽,我们可以开始了。
目录
网络设备驱动程序的开发,分解成以下步骤:
上:
中:
下:
一、设备检测
第一步,我们需要检测的网卡设备。 Linux内核提供了丰富的API检测PCI总线上的设备,我们这只用其中最简单的一个API——pci_find_device。
Table 1: Detecting the device
PCI标准为每个供应商分配一个唯一的Vendor ID,供应商会为每一个特定类型的设备分配一个唯一的Device ID。宏REALTEK_VENDER_ID、REALTEK_DEVICE_ID表示这些ID。你可以在RealTek8139规范的“PCI配置空间表”找到这些值。
二、设备启用
检测到设备后,我们使用设备之前,我必须先激活设备,这个步骤称为[启用设备]。表2所示的代码片段是[设备检测]和[设备启用]合并的代码。
在表2,函数probe_for_realtek8139执行以下任务:
现在,为了更好地理解代码,我们先暂停一下驱动程序代码的研究,转而看一下Linux内核是怎样[处理]设备和设备驱动的。我们将着眼于[网络设备的定义],内存映射I/O和独立端口I/O之间的差异,还有PCI配置空间的概念。
三、理解何为网络设备
我们是检测到了PCI设备,并启用它,但它只是一支硬件设备(网卡设备),而Linux的网络协议栈只认得[网络设备]。[网络设备]是一支逻辑设备,由结构net_device表征。也就是说,网络协议栈向[网络设备]发出命令,而[网络设备]的驱动将这些命令传递到PCI[网卡设备]。表3列出了结构net_device的一些重要数据域,这将在本文稍后使用。
Table 3: Structure net_device
上表只列出C结构net_device部分成员,不过,对于我们最小驱动程序,这些成员已经足够。以下简介这些成员的用途:
请特别注意,net_device没有接收数据包的成员函数,这是因为接收数据包是由设备的[中断处理程序]负责的,我们将在本文后面看到。
四、总线无关的设备访问
注:本小节摘自Alan Cox的《Bus-Independent Device Accesses》http://tali.admingilde.org/linux-docbook/deviceiobook.pdf
Linux提供了一个API集(下文称为[设备操作API]),抽象所有总线和设备的I/O操作,使设备驱动程序的编写独立于总线类型。
4.1内存映射的I/O
最广泛支持的I/O的操作是[内存映射I/O]。[内存映射I/O]是指,部分的CPU地址空间被解释为访问设备,而不是访问内存。一些体系结构为[内存映射I/O]的设备定义了固定的地址,但大多数体系提供了检测设备地址的方法。 PCI总线是很好的例子。本文不教你如何获得一个设备地址,假设你已经知道设备地址。
物理地址是unsigned long类型,你不能直接使用这些地址。你应该调用ioremap,来获得一个适合(传递给下面函数)的虚拟地址。当你使用完的设备(比如模块卸载),必须调用iounmap以返还虚拟地址给内核。
4.2访问设备
在Linux提供[设备操作API]中,驱动程序最常用的接口是访问的设备寄存器的读和写函数。 Linux提供了读取和写入8位,16位,32位和64位量的函数,分别为 byte, word, long, 和 quad,函数命名readb,readw,readl,readq,writeb,writew,writel和writeq。
有些设备(如帧缓冲)更倾向一次内发起超过8个字节的传输。对于这些设备,可使用memcpy_toio,memcpy_fromio和memset_io功能。不要使用memset或memcpy对I/O地址操作,因为它们不能保证[按顺序]复制数据。
[设备操作API]中的读写函数是假设严格[按照源码字面顺序]执行的,编译器不能对它进行乱序优化。如果希望设备读写有一定的优化,可使用原始的__readb函数(等原始无抽象的函数)。 但是要非常小心,要在适当的地方插入内存屏障指令——rmb()/wmb()
4.3独立端口IO
另外一种常用的IO操作是[独立端口IO]。端口IO的地址是独立于内存地址空间的,端口IO的访问速度不如内存映射I/O,地址空间也小很多。不过,不像内存映射I/O,访问端口IO的设备相对直观,不需要考虑以上提到的一些问题。
[设备操作API]中提供了访问端口IO的函数,分别操作字节(byte)、双字(word)和四字(long):inb, inw, inl, outb, outw 和 outl。
以上函数还有提供给慢速设备的变种:后加一“_p”;还有类似memcpy功能的ins 和 outs
五、理解PCI配置空间
RTL8139是一支PCI接口设备,PCI是一种通用的扩展总线,而非与CPU体系相关的本地总线(local bus),从而CPU不能直接对RTL8139寻址访问,必须经PCI总线控制器转译。PCI总线设计实现的核心是PCI总线控制器(有的地方译为PIC主桥,PCI Host Bridge),它将整个系统划分两个数字通信域,两个域独立编址。一个是原来CPU与内存和设备通信的[CPU域],一个是PCI总线控制器的(因它本身就是一CPU),这里称为[PCI总线域]。为了跨越两域通信,系统将CPU域划出一个“window”——将CPU部分寻址空间划给PCI总线用。PCI总线控制器对这部分地址进行管理,实现即插即用等一些现代总线功能。而所谓的[配置空间]只是配合PCI总线控制器实现地址管理提供必要的状态信息[注]。
注:个人觉得[配置空间]用“空间”一词欠佳,容易混淆其它地址空间概念,增加理解PCI总线原理的难度。
[配置空间]是每支PCI设备(包括PCI桥)集成一集寄存器,[配置空间]是面向PCI总线控制器而言的,此空间的基地址是PCI设备的拓扑位置(总线号/设备号/功能号)。PCI定义每支PCI设备的[配置空间]为256字节,如下图,其中最前面的64个字节已由标准定义,余下的空间由设备自定义。
围绕[配置空间]有两种事务和三种操作角色,事务是[配置]和[使用配置],角色有静态配置的厂商和动态配置的操作系统,还有使用配置的设备驱动。静态配置的例子,如厂商在设备生产时配置其Vendor ID和Device ID;动态配置的例子,如操作系统初始化代码根据PCI设备的拓扑位置,配置设备的基地址(Base Address0~5)[注]。
注:这个地址属于PCI总线域的地址,而不是CPU域的地址。
使用配置的例子,如设备驱动的初始接口函数读取基地址寄存器(Base Address Registers),确定设备接口的基地址,下面的RTL8139设备初始化时你可以看到具体例子。
六、初始化net_device
现在我们回到驱动程序代码的开发上来。刚才我们已经讨论了设备驱动模块初始化中的设备检测和启用的任务,还有网络设备的表征结构,接下来我们先看看逻辑设备的初始化任务。
首先,作为一支特殊的网络设备,除了有标准的net_device表征,8139有其特殊数据,这是由C结构rtl8139_private 表征,由net_device->priv指向。rtl8139_private的定义如下:
Table 4: rtl8139_private structure
现在我们扩展init_module 函数,添加逻辑设备的初始化的任务。先看代码:
首先probe_for_realtek8139函数检测和启用设备后返回一个PCI设备——pdev,然后rtl8139_init用pdev初始化rtl8139_private,转而初始化网络设备rtl8139_dev。
我们下一个目标是得到(初始化)设备的基地址——net_device的base_addr域。这是设备寄存器的内存映射的起始地址。本设备驱动程序只使用内存映射IO。
为了取得基地址,我们利用了内核PCI总线子系统提供的API:pci_resource_start, pci_resource_end, pci_resource_len, pci_resource_flags。注意这些API函数的第二个参数——BAR号1。PCI规定PCI设备最多可以申请6个PCI总线地址区,这些空间区的基地址分别保存在6个BAR里。在RealTek8139手册定义里,RTL只申请了两个区,第一个BAR(编号为0)是I/OAR,第二个 BAR(编号为1)是MEMAR。由于本设备驱动程序只使用内存映射IO,故BAR选用1。
现在,在使用这些地址之前,我们还有两件事要做。
这两个事就是,第一,为设备驱动保留这些地址(调用pci_request_regions函数),以免被误用;第二,将这些物理地址重映射(remap);这在前面“内存映射的I/O”小节已经提到,驱动代码不能用直接使用物理地址。重映射后的地址io_addr填入 net_device的base_addr域后,我们可以读定设备的寄存器了。
剩下的代码比较直观和易理解了。
我们用了一个for循环来读取设备的硬件地址和广播地址(注意这回是直接用内核[设备操作API]的readb,而不是 PCI总线系统API),设备的硬件地址位于基地址的最前面。另外值得注意的是几个网络设备的接口函数指针,如open,hard_start_xmit 等,它们指向还没有实现的函数。为了编译驱动模块并进行测试,到此暂时为这些接口函数写一些Dummy测试代码。
Table 6: Dummy functions
最后是注销函数:
Table 7: Function cleanup_module
到此,一支完整的8139网卡设备驱动基本完成了,当然目前还只是一个模板,没有实质性的功能。我们可以编译并安装它了。
Table 8: Compiling the driver
安装不出问题的话,我们可以用SHELL命令进行测试:”ifconfig”, “ifconfig – a”, “ifconfig rtl8139 up”, “ifconfig” 和 “ifconfig rtl8139 down”。如无意外,”ifconfig – a” 会列出设备rtl8139;执行 “ifconfig rtl8139 up”会返回消息”function rtl8139_open called”等等……
好了,通过测试后,下一步是实现网络设备真正的数据收发了。为了更好理解实现代码,我们还是需要一些背景知识——理解RTL8139收发原理。