Embedded 版 (精华区)
发信人: he (hehe), 信区: Embedded_system
标 题: (ldd) Ch14-网络驱动程序(下) (zz)
发信站: 哈工大紫丁香 (2001年06月24日17:23:00 星期天), 站内信件
打开和关闭
我们的驱动程序可以在模块加载和核心引导时探测接口。下一步是给接口赋一个地址，
这样驱动程序就可以通过它交换数据了。打开和关闭一个接口由ifconfig命令完成。
当使用ifconfig为一个接口赋地址时，它完成两项工作。第一，它通过
ioctl(SIOCSIFADDR)(即Socket I/O Control Set InterFace ADDRess)来赋地址。接着
它通过ioctl(SIOCSIFFLAGS)(即Socket I/O Control Set InterFace FLAGS) 对dev->fl
ag中的IFF_UP置位来打开接口。
至于设备，ioctl(SIOCSIFADDR)设置dev->pa_addr，dev->family，dev->pa_mask，dev-
>pa_brdaddr，没有驱动程序函数被调用----这个任务是设备无关的，由核心来完成。不
过，后一个命令ioctl(SIOCSIFFLAGS)为设备调用open方法。
类似地，当一个接口关闭时，ifconfig使用ioctl(SIOCSIFFLAGS)来清除IFF_UP，并且调
用stop方法。
两个设备方法在成功时都返回0，发生错误时，通常返回一个负值。
至于代码，驱动程序必须执行与字符和块设备同样的工作。open请求它所需要的所有的
系统资源，并告诉接口启动；stop则关闭接口，并释放系统资源。
如果驱动程序不准备使用共享中断（例如，它不打算与旧的核心兼容），还有最后一步
需要做。核心引出一个irq2dev_map阵列，它由IRQ号寻址，持有空指针；驱动程序也许
想用这个数组将中断号映射到指向device结构的指针。这是在不使用接口处理程序的情
况下，在一个驱动程序里支持一个以上接口的唯一方法。
另外，在接口可以和外界通信以前，硬件地址还必须从板上复制到dev->dev_addr。硬件
地址可以按驱动程序的意愿在探测时或打开时被赋值。snull软件接口时从open里对其赋
值；它用两个ASCII串伪造一个硬件号码。地址的第一个字节是个空字符（在后面的“地
址解析”中解释）。
结果得到的open代码如下所示：
（代码319）
（代码320 #1）
正如你所看到的，device结构中的几个域被修改了。start表明接口已准备好， tbusy断
言发送者不忙（也就是说，核心可以发出一个包）。
stop方法是open的操作的反转。由于这个原因，实现 stop的函数通常调用 close。
（代码320 #2）
包发送
网络接口执行的最重要的工作是数据发送和接收。我准备从发送开始，因为它相对比较
简单。
当核心需要发送一个数据包时，它调用hard_start_transmit方法将数据放到一个输出队
列。核心处理的每个包包含在一个套接字缓冲区结构（struct sk_buff）中，其定义见<
linux/skbuff.h>。这个结构从Unix用来表示一个网络连接的抽象，即套接字得名。即使
接口与套接字无关，每个网络包在较高的网络层中一定属于某个套接字，任何套接字的
输入输出缓冲区都是sk_buff结构的列表。同样的sk_buff结构在整个Linux网络子系统中
都被用来承载网络数据，但在考虑接口时，一个套接字缓冲区就是一个包。
指向sk_buff的指针通常被称做skb，我将在示例和正文中都使用使用这个习惯。
套接字缓冲区是一个复杂的结构，核心提供一组函数来对其操作。这些函数在后面的“
套接字缓冲区”中描述----目前，知道sk_buff的一些基本事实已足以写出可工作的驱动
程序。另外，我习惯于在扎入另人讨厌的细节之前先弄明白是如何工作的。
传递给hard_start_xmit的套接字缓冲区含有物理包，它具有传输层的包头。接口不需要
修改被发送的数据。skb->data指向被发送的包，skb->len是它的长度，以八元组为单位
。
snull的包发送代码如下所示；物理发送机制被隔离在另一个函数中，因为每个接口驱动
程序必须按照被驱动的特定硬件来实现它。
（代码321）
这样发送函数只进行一些清晰的对包的检查，并通过硬件相关的函数发送数据。在一个
中断表明一个“发送结束”的条件时，dev->tbusy被清除。
包接收
从网络中接收数据比发送要复杂一些，因为必须分配一个sk_buff，并从一个中断处理程
序中将其交递给高层----接收包的最好的办法是通过中断，除非接口是象snull一样是纯
软件的，或是环回接口。尽管有可能写轮询的驱动程序，而且在正式的核心里也的确有
几个，但中断驱动的要好的多，不管是在数据吞吐率还是计算需求上。由于绝大多数网
络接口都是中断驱动的，我不打算谈论轮询实现，它只是利用了核心计时器。
snull的实现是将硬件细节和设备无关的工作分离开的。这样，在硬件收到一个包后，sn
ull_rx被调用，它已经在计算机的内存中了。snull_rx因此收到一个指向数据的指针和
包的长度。。这个函数唯一的责任就是将包和一些额外信息发送到网络代码的高层。其
代码与数据指针及长度获得的方法无关。
（代码322）
这个函数足够通用，可以作为任何网络驱动程序模版，但在你有信心重用这个代码段之
前还需要一些解释。
注意缓冲区分配函数需要知道数据长度。者避免了在调用kmalloc时浪费内存。dev_allo
c_skb以原子优先级调用分配函数，因此它也可以在中断时安全地使用。核心还提供了套
接字缓冲区分配的其它一些接口，但不值得在这里介绍；套接字缓冲区在本章后面的“
套接字缓冲区”中详细介绍。
一旦有了一个有效的skb指针，就可以通过调用memcpy将包数据复制到这个缓冲区。skb_
put更新缓冲区中数据尾的指针，并返回一个指向新生成空间的指针。
不幸的是，包头中没有足够的信息来正确处理网络层----在缓冲区向上层传递之前，dev
和protocol域必须被赋值。接着我们需要指定如何执行校验和（snull不进行任何校验和
）。skb->ip_summed可能的策略为：
CHECKSUM_HW
板子用硬件执行校验和。一个硬件校验和的离子是Sparc HME接口。
CHECKSUM_NONE
校验和完全有软件完成。对新分配的缓冲区，这是缺省的策略。
CHECKSUM_UNNECESSARY
不做任何校验和。这是snull和环回接口的策略。
在1.2核心版本中没有校验和选项和ip_summed。
最后，驱动程序更新它的统计计数器记录一个新包被收到了。统计结构有几个域组成，
最重要的是rx_packets和tx_packets，它们包含收到的和发送的包的个数。所有的域在
后面的“统计信息”中给出一个彻底的描述。
包接收的最后一步由netif_rx完成，它将套接字缓冲区递交到上一层。
中断驱动的操作
大多数硬件接口以中断处理程序的方式控制。接口中断处理器表明两种事件中的一种：
一个新包到达了或一个包发送完成了。这种一般化并不是总适用，但它基本上揭示了与
异步包传送相关的问题。PLIP和PPP是不适用这种一般化的例子。它们处理同样的事件，
但低级中断处理略有不同。
一般的中断例程可以通过检查在硬件设备上的一个状态寄存器来分辨新包到达中断与完
成发送的通知。snull接口工作方式类似，但其状态字在dev->priv中。网络接口的中断
处理程序看起来如下：
（代码324）
处理程序的第一个任务是接收一个指向正确的device结构的指针。你可以用irq2dev_map
[]（假如你在打开是给它赋了一个值）或者接收到的dev_id指针作为一个参数。如果你
希望驱动程序可以与新于1.3.70的核心工作，你必须使用irq2dev_map[]，因为早期版本
中没有dev_id。
这个处理程序中有趣的部分是处理“发送完成”的部分。接口通过清除dev->tbusy并标
志网络下半部例程来相应发送完成。如果net_bh的确运行了，它会试图发送所有等待的
包。
另一方面，包接收并不需要任何特殊的中断处理。所有需要做的就是调用snull_rx。
实际上，当netif_rx被接收函数调用时，它所进行的实际操作只有标志net_bh。换句话
说，核心在一个下半部处理程序中完成了所有网络相关的工作。因此，网络驱动程序应
该总是宣称它的中断处理程序太慢，因为下半部将会更早地执行（见第九章中“下半部
设计”）。
套接字缓冲区
我们已经讨论了于网络接口相关的多数内容。下面几节我们将更细地讨论sk_buff时如何
设计的。这几节既介绍这个结构的主要域，也介绍在套接字缓冲区上操作的函数。
尽管并没有理解sk_buff内部的严格需要，但是如果能理解它的内容将会有助于你解决问
题和优化代码。例如，如果你看了loopback.c，你会发现一个基于sk_buff内部知识的优
化。
我不打算在这里描述整个结构，而只是那些可能被驱动程序用到的域。如果你想知道更
多，你可以看<linux/skbuff.h>，结构的定义和函数的原形都在那里定义。至于这些域
和函数如何使用的细节可以通过浏览核心源码得到。
重要的域
出于我们的目的，结构里重要的域是那些驱动程序的作者可能要用到的域。它们如下所
示，无特别顺序。
struct device *dev;
设备接收或者发送这个缓冲区。
__u32 saddr;
__u32 daddr;
__u32 raddr;
源地址，目的地址，和路由器地址，由IP协议使用。raddr是包要到达其目的地的第一步
。这些域在包被发送前被设置，收到之后就不必赋值了。到达hard_start_xmit方法的外
出包已经有了一个合适的硬件包头设置反映了“第一步”信息。
unsigned char *head;
unsigned char *data;
unsigned char *tail;
unsigned char *end;
这些指针用来访问包中的数据。head指向分配空间的开始，data是有效八元组的开始（
通常比head略大），tail是有效八元组的结束， end指向tail可以到达的最大地址。观
察它们的另一个方法是：可用缓冲区空间为skb->end-skb->head，当前使用的数据空间
为skb->tail-skb->data。这种处理内存区域的清晰方法在1.3开发时才实现。这是snull
没有被移植在Linux1.2上编译的主要原因。
unsigned long len;
数据本身的长度（skb->tail-skb->head）。
unsigned char ip_summed;
这个域有驱动程序对进来包设置，由TCP/UDP校验和使用。它在前面的“包接收”中介绍
窗柚茫蒚CP/UDP校验和使用。它在前面的“包接收”中介绍
过。
unsigned char pkt_type;
这个域被内部用来发送进来包。驱动程序负责将其设置为PACKET_HOST（这个包是我的）
， PACKET_BROADCAST，PACKET_MULTICAST，或是PACKET_OTHERHOST（不，这个包不是我
的） 。以太网驱动程序并不显式地修改pkt_type，因为eth_type_trans会为它做这件事
。
union { unsigned char *raw; […]} mac;
与pkt_type类似，这个域被用来处理进来包，必须在包接收时设置。函数eth_type_tran
s为以太网驱动程序负责这件事。非以太网驱动程序应设置skb->mac.raw指针，后面“非
以太网包头”中将会提到。
结构中其余的域并无特别兴趣。它们被用来维护缓冲区列表，解释占有缓冲区的套接字
的内存，等等。
在套接字缓冲区上操作的函数
使用sock_buff的网络设备通过正式的接口函数在这个结构上操作。有很多在套接字缓冲
区上操作的函数，下面是最有趣的一些：
struct sk_buff *alloc_skb(unsigned int len, int priority);
struct sk_buff *dev_alloc_skb(unsigned int len);
分配一个缓冲区。alloc_skb分配一个缓冲区并初始化skb->data和skb->tail到skb->hea
d。 dev_alloc_skb函数（在Linux1.2中没有）一个快捷方式，它用GFP_ATOMIC优先级调
用alloc_skb，并反转skb->head和skb->data之间的16个字节。这个数据空间可以用来“
推”硬件包头。
void kfree_skb(struct sk_buff *skb, int rw);
void dev_kfree)skb(struct sk_buff *skb, int rw);
释放一个缓冲区。kfree_skb被核心内部使用。驱动程序应该使用dev_kfree_skb，在拥
有缓冲区的套接字需要再次使用它的情况下，它可以正确地处理缓冲区加锁。两个函数
的rw参数是FREE_READ或FREE_WRITE。这个值用来跟踪套接字的内存。外出缓冲区应用
FREE_WRITE来释放，而进来的则使用FREE_READ。
unsigned char *skb_put(struct sk_buff *skb, int len);
这个线入函数更新结构sk_buff的tail和len域，它被用来在缓冲区尾加入数据。其返回
值是skb->tail以前的值（或者说，它指向刚生成的数据空间）。有些驱动程序通过调用
ins(ioaddr,skb_put(…))或memcpy(skb_put(…), data,len)来使用这个返回值。这个
函数及下面的一些在为Linux1.2构造模块是不存在。
unsigned char *skb_push(struct sk_buff *skb, int len);
这个函数减小skb->data，增加skb->len。类似于skb_put，除了数据是加在包开始而不
是结尾。返回值指向刚生成的空间。
int skb_tailroom(struct sk_buff *skb);
这个函数返回为在缓冲区中放置数据的可用空间量。如果驱动程序在缓冲区中放了多于
它能承载的数据，系统可能回崩溃。你也许会反对并认为，用printk指出这个错误已经
足够了，而内存崩溃对系统太有害了，开发者肯定要采取一些措施。但实际上，如果缓
冲区被正确分配了，你根本不必检查可用空间。因为驱动程序通常在分配缓冲区之前获
得包大小，只有有严重缺陷的驱动程序才可能在缓冲区内放太多的数据，崩溃可以认为
是应得的惩罚。
int skb_headroom(struct sk_buff *skb);
返回数据前面得可用空间量，也就是可以向缓冲区中“推”多少八元组。
void skb_reserve(struct sk_buff *skb, int len);
这个函数增加data和tail。它可以用来在填充缓冲区前预留空间。大多数以太网接口在
包前预留两个字节；这样IP头可以在一个4字节以太网头之后，在16字节边界对齐。snul
l完成得很好，尽管在“包接收”中并未提到这一点，那主要是为了避免彼时引入过多得
概念。
unsigned char *skb)pull(struct sk_buff *skb, int len);
从包头中删除数据。驱动程序并不用这个函数，但为了完整性也包含在这里。它减少skb
->len，增加skb->data；这是从进来包的开始剥出以太网包头的方法。
核心还定义了几个在套接字缓冲区上操作得别的函数，但它们主要应用于网络代码得高
层，驱动程序并不需要它们。
地址解析
地址解析
以太网通信最急迫得问题之一是硬件地址（接口得唯一标志符）与IP号码之间的关联。
大多数协议都有类似问题，但我只向重点讨论一下以太网类得情况。我力图给出一个全
面得描述，因此我将显示三种情况：ARP，没有ARP的以太网头(象plip)，以及非以太网
包头。
在以太网上使用ARP
地址解析得一般方法是ARP，即地址解析协议。幸运的是，ARP由核心管理，以太网接口
不必为支持ARP做任何特殊工作。只要在打开时正确地设置了dev->addr和dev->addr_len
，驱动程序不需担心任何从IP号码到物理地址的转换；ether_setup将正确的设备方法赋
给dev->hard_header和dev->rebuild_header。
当一个包被构造时，以太网包头由dev->hard_header来布局，并由dev->rebuild_header
在后来填充，它使用ARP协议将未知的IP号码映射到地址上。驱动程序作者不必知道这个
过程的细节去写一个可工作得驱动程序。
越过ARP
简单得点到点网络接口如plip可以从以太网包头获益，但却要避免来回发送ARP包得开销
。snull中得示例代码就属于这一类网络设备。snull不能使用ARP，因为驱动程序修改被
发送得包得IP地址，而ARP包也交换IP地址。
如果你的设备想用一般的硬件包头，却不想运行ARP，你需要越过缺省的dev->rebuild_h
eader方法。这就是snull实现的方法，这个简单的函数有三条语句：
（代码329）
事实上，并没有指定eth->h_source和eth->h_dest内容的实际需要，因为这些值只被用
来进行包得物理传送，而一个点到点得连接保证能将包发送到它的目的地，而与硬件地
址无关。snull重构包头的原因是向你演示，当eth_rebuild_header不可用时，一个真实
的网络接口的重构函数是如何实现的，
当接口收到一个包时，硬件包头只被eth_type_trans使用。我们在snull_rx中已经见过
这个调用：
skb->protocol=eth_type_trans(skb,dev);
这个函数从以太网包头中抽取协议标志符（在这里是ETH_P_IP）；它还要赋值skb->mac.
raw，从包数据中删去硬件包头，并设置skb->pkt_type。最后一项在skb分配时缺省为PA
CKET_HOST（表明包被指向这个主机），当然它也可以改为符合以太网目的地址得其它值
。
如果你的接口是点到点连接，你将无法收到未想到的选播包。为避免这个，你必须记住
轿聪氲降难〔グＮ苊庹飧觯惚匦爰亲�
那些第一个八元组的最低位（LSB）是0的目的地址将被指向单个主机（也就是说，它是P
ACKET_HOST或PACKET_OTHERHOST）。plip驱动程序用0xfc作为它的硬件地址的第一个八
元组，而snull用0x00。这两个地址都导致一个可工作的以太网类的点到点连接。
非以太网包头
这节简要地介绍硬件包头是如何用来封装相关信息的。如果你希望了解细节，你可以从
核心源码或特别传输介质的技术文档中得到。我们刚才已经看到硬件包头除了含有目的
地址外，还有一些信息，其中最重要的是通信协议。
不过，并不是每个协议都要提供所有的信息。象plip或snull之类的点到点连接可以避免
传送整个以太网包头，同时不失去一般性。hard_header设备方法从核心接收传送信息--
--包括协议级和硬件地址。它也收到16位的协议号。例如IP由ETH_P_IP标志。驱动程序
应能正确地象接收主机传送包数据和协议号。点到点连接可以在硬件包头中省略地址，
只传送协议号，因为传送是有保证的，与源和目的地址无关。一个只有IP的连接甚至什
么硬件头都不传送。两种情况下，所有的工作都由hard_header完成，rebuild_header除
了返回0外什么都不做。
当包在连接的另一端被捡起时，接收函数将正确地设置skb->protocol，skb->pkt_type
，和skb->mac.raw。
skb->mac.raw是一个被网络高层代码实现的地址解析机制使用的字符指针（例如，net/i
方馕龌剖褂玫淖址刚耄ɡ纾琻et/i
pv4/arp.c）。它必须指向一个与dev->type匹配的机器地址。设备类型的可能值被定义
在<linux/if_arp.h>；以太网接口用ARPHRD_ETHER。例如，下面是eth_type_trans处理
收到包的以太网包头的方法：
skb->mac.raw=skb->data;
skb_pull(skb, dev->hard_header_len);
在最简单的情况下（无包头的点到点连接），skb->mac.raw可以指向一个含有这个接口
的硬件地址的静态缓冲区，protocol可以被置为ETH_P_IP，packet_type仍维持其缺省值
PACKET_HOST。
加载时配置
用户可以用几个标准的关键字来配置接口。任何新的网络模块都应遵循这个标准：
io=
为接口设置I/O端口的基地址。如果系统中安装了不只一个接口，那么可以用一个由逗号
分隔的列表来指定。
irq=
设置中断号。和上面一样，可以指定不止一个值。
换句话说，一个装了两个own_eth接口的Linux用户可能用下面的命令行来加载模块：
insmod own_eth.o io=0x300, 0x320 irq=5,7
如果指定0值，那么io=和irq=选项都要被探测。因此用户可以通过指定io=0来强制探测
。如果用户名优指定任何选项，多数驱动程序通常都探测一个接口，但有时，模块可能
被禁止探测。（见ne.c中关于NE2000设备的探测）。
设备驱动程序应该象刚才描述的这样工作。ISA设备的典型实现如下所示，假设驱动程序
最多可以支持四个接口：
（代码331）
这段代码缺省探测一个板子，并总是自动探测中断，但用户可以改变这种行为。例如，i
o=0,0,0将探测三块板子。
除了使用io和irq外，驱动程序的作者可以随意增加其它加载时配置参数。也没有已建立
的命名标准。
运行时配置
用户有时可能希望在运行时改变接口的配置。例如，当中断号无法探测时，想对它正确
配置的唯一办法就是“尝试—错误”技术。一个用户空间的程序可以获取设备的当前配
置，并通过在一个打开的套接字上调用ioctl来设置一个新的配置。例如，应用ifconfig
使用ioctl为接口设置I/O端口。
我们前面知道一个为网络接口定义的方法中的一个是set_config。这个方法被用来在运
行时设置或改变一些接口特征。
当一个程序询问当前配置时，核心从结构device中抽取相关信息，而不通知驱动程序；
另一方面，当一个新的配置被传递给接口时，set_config被调用，这样驱动程序就可以
检查这些值并采取相应的动作。这个驱动程序方法对应下面的原形：
int (*set_config)(struct device *dev, struct ifmap *map);
map参数指向一个由用户程序传递的结构的拷贝；这个拷贝已经在核心空间，所以驱动程
序不需要调用memcpy_from _fs。
结构ifmap的域是：
unsigned long mem_start;
unsigned long mem_end;
unsigned short base_addr;
unsigned char irq;
unsigned char dma;
这些域对应着结构device中的域。
Unsigned char prot;
Unsigned char prot;
这个域对应着dev中的if_port。map->port的含义是设备特定的。
当一个进程为设备发出ioctl(SIOCSIFMAP)(即Socket I/O Control Set InterFace
MAP)时，set_config设备方法被调用。这个进程在时强制使用新值之前，应该发出ioctl
(SIOCGIFMAP)(即Socket I/O Control Get InterFace MAP)，这样驱动程序只需要查看d
ev和ifmap结构不匹配的地方。Map中任何不被驱动程序使用的域均可以略过。例如，一
个不使用DMA的网络设备可以忽略map->dma。
snull实现被设计成可以显示驱动程序是如何针对配置改变而动作的。对snull来说，没
有一个域由物理意义。但出于说明的目的，代码禁止改变I/O地址，允许改变IRQ号，并
忽略其它选项，从而显示这些改变是如何被响应、拒绝、或是忽略的。
（代码333 #1）
这个方法的返回值被作为发出的ioctl系统调用的返回值，对于没有实现set_config的驱
动程序则返回-EOPNOTSUPP。
如果你对接口配置如何从用户空间访问感到好奇，请看misc-progs/netifconfig.c，它
可以用来与set_config比较。下面是一个示例运行的输出：
（代码333 #2）
自定义ioctl命令
我们已经看到ioctl系统调用是为套接字实现的。SIOCSIFADDR和SIOCSIFMAP是“套接字i
octl”的例子现在让我们看看这个系统调用的第三个参数是如何被网络代码使用的。
当ioctl系统调用在套接字上被调用时，其命令号是在<linux/sockios.h>定义的符号之
一，并且函数sock_ioctl直接调用一个协议特定的函数（这里协议指使用的主要网络协
议，如IP或AppleTalk）。
任何协议层不认识的ioctl命令被传递给设备层。这些设备相关的ioctl命令从用户空间
接收第三个参数，即结构ifreq*；这个结构在<linux/if.h>中定义。SIOCSIFADDR和SIOC
SIFMAP命令实际上是工作在ifreq结构上。SIOCSIFMAP的额外参数，尽管定义为ifmap，
是ifreq的一个域。
除了使用标准的调用，每个接口可以定义它自己的ioctl命令。例如plip接口允许通过io
涌诳梢远ㄒ逅约旱膇octl命令。例如plip接口允许通过io
ctl修改其内部超时值。套接字的ioctl实现将16个命令看作对接口是私有的：从SIOCDEV
PRIVATE到SIOCDEVPRIVATE+15。
当这些命令中的一个被认识时，dev->do_ioctl在相关的接口驱动程序里被调用。这个函
数接收与通用目的的ioctl函数使用的一样的ifreq*指针。
Int (*do_ioctl)(struct device *dev, struct ifreq *ifr, int cmd);
Ifr指针指向核心空间的一个地址，放有被用户传来结构的一个拷贝。在do_ioctl返回后
，这个结构又被拷贝回用户空间；这样，驱动程序可以使用私有命令来接收和返回数据
。
设备特定的命令可以选择使用结构ifreq中的域，但它们已经带有标准的含义，驱动程序
不太可能根据自己的需要适配这个结构。域ifr_data是个caddr_t项（一个指针），用于
设备特定的需要。驱动程序和调用ioctl命令的程序应在ifr_data的使用上取得一致。例
如，pppstats使用设备特定的命令来从ppp接口驱动程序中获取信息。
在这里不值得给出do_ioctl的一个实现，但根据本章的信息和核心的例子，你应能在需
要的时候写出一个。不过注意，plip实现不正确地使用了ifr_data，不应做为ioctl实现
的一个例子。
统计信息
一个驱动程序需要的最后一个方法是get_stats。这个方法返回指向设备统计信息的一个
指针。它的实现相当容易：
（代码335）
返回有意义的统计信息所需的实际工作散布在驱动程序中，不同的域分别被更新。下表
给出enet_statistics结构中最有趣的几个域。
int rx_packets;
int tx_packets;
这两个域含有接口成功传送的进来和外出包的总数。
int rx_errors;
int tx_errors;
int tx_errors;
出错的接收和发送的数目。接收错可能是错误的校验和、错误的包大小，以及其它问题
的结果。发送错误不太常见，一般都是线缆的问题。
int rx_dropped;
int tx_dropped;
在接收和发送时被丢弃的包的个数。当包数据没有可用内存时，包便被丢弃了。tx_drop
ped很少使用。
这个结构还有几个域，可以用来细分发送和接收时发生的错误。感兴趣的读者可以看<li
nux/if_ether.h>中结构的定义。
选播
“选播”包是指一个网络包，它将要被多于一个，但又不是全部的主机接收。
这个功能是通过给一组主机赋以特殊的硬件地址来获得的。指向这些特殊地址中的一个
的包将被这个组中所有的主机收到。在以太网的情况下，一个选播地址是将目的地址中
第一个八元组的最低位设置而得到，而所有的设备板子都在其硬件地址中将这一位清除
。
处理主机组以及硬件地址的棘手部分都有应用或核心完成了，接口驱动程序并不需要处
理这些问题。
选播包的发送很简单，与其它包完全一样。接口在传输介质上发送它们，根本不管目的
地址。核心必须设置一个正确的硬件目的地址；rebuild_header设备方法（如果被定义
）并不需要查看它整理的数据。
而另一方面，接收选播包需要设备的一些合作。当一个“有趣的”选播包被收到时（也
就是一个包的目的地址确定一组主机，其中包含了这个接口），硬件应该通知操作系统
。这意味着硬件过滤器应被设计为能够区别不同的选播地址。这个过滤器在接口的一般
操作中，将网络包的地址与其自己的硬件地址进行匹配。
典型地，在考虑选播的情况下，硬件可分为一下三类：
l 不能处理选播的接口。这类接口要么接收指向自己硬件地址的包（包括播送
包），要么节收所有的包。它们接收选播包是通过接收所有的包实现的，这样，操作系
统中会充斥着大量“无意义”的包。一般我们不认为这类接口为支持选播的，驱动程序
不在dev->flags中置IFF_MULTICAST。
点到点接口是一种特殊情况，它们通常接收所有的包，根本不进行任何硬件过滤。
l 能区别选播包和其它包（主机到主机或播送）的接口。这类接口可以被要求
接收所有的选播包，然后用软件来判断自己是否是有效的接收者。这种情形引入的开销
是可以接收的，因为一个典型的网络中选播包的数量都很少。
l 能够进行选播地址硬件检测的接口。可以给这类接口一组需要接收的选播地
址，它们会忽略其它的选播包。这对核心来说是最优化的情况，因为不会浪费处理器事
件去丢弃接口收到的“无意义”的包。
核心试图利用高级接口的能力，能最好地支持第三类接口（用途最广）。因此，当有效
的选播地址被改变时核心应通知驱动程序，它把新的一组地址传给驱动程序，这样它可
以按照新的信息更新硬件过滤器。
核心对选播的支持
核心对选播的支持
下面是与驱动程序的选播能力相关的数据结构和函数的概括：
void (*dev->set_multicast_list)(struct device *dev)
当与设备相关的机器地址表改变时调用这个设备方法。当dev->flags被修改时它也被调
用，因为有些标志也要求你重新配置硬件过滤器。这个方法接收一个指向device结构的
指针作为参数，返回void。对实现这个方法不感兴趣的驱动程序可以留域为NULL。
struct dev_mc_list *dev->mc_list
这是域设备相关的所有选播地址的链表。这个结构的实际定义在本节结束时介绍。
int dev->mc_count
链表项数。这个信息有点冗余，但检查mc_count是否为0是优于列表检查的一个有用的快
捷方式。
IFF_MULTICAST
除非驱动程序在dev->flags中设置了这个标志，接口将不必处理选播包。当dev->flags
改变时，至少set_multicast_list会被调用。
IFF_ALLMULTI
dev->flags中的这个标志被网络软件设置以告诉驱动程序从网络中抽取所有播送包。这
在multicast-routing被使用时发生。如果这个标志被置位，dev->mc_list将不再使用去
过滤选播包。
IFF_PROMISC
当接口被置为杂乱模式时，dev->flags中的这个标志被设置。所有的包都被接口抽取，
不考虑dev->mc_list。
驱动程序开发者需要的最后一点信息是结构dev_mc_list的定义，它居于<linux/netdevi
ce.h>中。
（代码337）
由于选播和硬件地址与包的实际发送无关，这个结构可在不同的网络实现上移植，每个
地址由一串八元组和一个长度确定，就象dev->dev_addr。
一个典型的实现
描述set_multicast_list设计的最号办法是给出一些伪代码。
下面的函数是这个函数在一个全特征(ff)驱动程序中的一个典型实现。说这个驱动程序
是全特征的是因为它控制的接口有一个复杂的硬件包过滤器，它可以存放一个由本机接
收的选播地址表。这个表的最大尺寸是FF_TABLE_SIZE。
所由带有前缀ff_的函数是放置硬件特定操作的地方。
（代码338）
如果这个接口不能在硬件过滤器中存储到来包的选播表，那么这个实现还可以简化。在
这种情况下，FF_TABLE_SIZE减为0，代码的最后四行也不需要了。
现在，接口板一般不能存储选播表。不过，这并不是一个大问题，因为网络代码的高层
会负责将不需要的包丢弃。
如我前面建议的，即使不能处理选播包的接口也需要实现set_multicast_list方法，这
样当dev->flags发生改变时可以被通知。我称这个为“无特征”(nf)的实现。它非常简
单，如下面所示：
（代码339）
处理IFF_PROMISC是很重要的，因为不然的话，用户将无法运行tcpdump或其它一些网络
分析工具。另一方面，如果接口运行一个点到点的连接，则没有任何实现set_multicast
_list的必要，因为它们接收所有的包。
快速参考
本节提供在本章中介绍的概念的参考。它也解释了驱动程序应包含的每个头文件的作用
。不过，device和sk_buff的每个域的列表，就不再重复了。
#include <linux/netdevice.h>
这个头文件含有struct device的定义，还包含了网络驱动程序需要的几个其它头文件。
void netif_rx(struct sk_buff *skb);
这个函数在中断时可以被调用通知核心一个包被收到了，并且封装在一个套接字缓冲区
中。
#include <linux/if.h>
被netdevice.h包含，这个文件声明接口标志(IFF_macros)和结构ifmap，它在网络驱动
程序的ioctl实现中用重要的作用。
#include <linux/if_ether.h>
ETH_ALEN
ETH_P_IP
struct ethhdr;
struct enet_statistics;
被netdevice.h包含，if_ether.h定义所有的ETH_macros，用来表示八元组长度（象地址
长度）和网络协议（象IP）。它也定义了结构ethhdr和enet_statistics。注意，不要看
enet_statistics的名字和包含它的头文件，事实上，所有的接口都要用到它，不仅仅是
以太网。
#include <linux/skbuff.h>
结构sk_buff和一些相关结构的定义，以及在缓冲区上操作的线入函数。这个头文件包含
在netdevice.h中。
#include <linux/etherdevice.h>
void ether_setup(struct device *dev)；
这个函数为以太网驱动程序设置大多数设备方法为通用目的的实现。它同样设置dev->fl
ags，并且在名字中的第一个字符是空格或空字符时，将下一个可用的ethx名赋给dev->n
ame。
unsigned short eth_type_trans(struct sk_buff *skb, struct device *dev)
当以太网接口收到一个包，这个函数将被调用来设置skb->pkt_type。返回值是一个协议
号，通常被存在skb->protocol中。
#include <linux/sockios.h>
是一个协议
号，通常被存在skb->protocol中。
#include <linux/sockios.h>
SIOCDEVPRIVATE
这是16个ioctl命令的第一个，可以被每个驱动程序实现以供私用。所有的网络ioctl命
令都在sockios.h中定义。
--
※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 202.118.235.250]
Powered by KBS BBS 2.0 (http://dev.kcn.cn)
页面执行时间：208.819毫秒