00000004.htm

一份很好的linux入门资料

后调用netif_rx()传递给上层处理。&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
2.2&nbsp;网络驱动程序的基本方法&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;网络设备做为一个对象，提供一些方法供系统访问。正是这些有统一接口的方法，&nbsp;<BR>
掩蔽了硬件的具体细节，让系统对各种网络设备的访问都采用统一的形式，做到硬件&nbsp;<BR>
无关性。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;下面解释最基本的方法。&nbsp;<BR>
2.2.1&nbsp;初始化(initialize)&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;驱动程序必须有一个初始化方法。在把驱动程序载入系统的时候会调用这个初&nbsp;<BR>
始化程序。它做以下几方面的工作。检测设备。在初始化程序里你可以根据硬件的&nbsp;<BR>
特征检查硬件是否存在，然后决定是否启动这个驱动程序。配置和初始化硬件。在&nbsp;<BR>
初始化程序里你可以完成对硬件资源的配置，比如即插即用的硬件就可以在这个时&nbsp;<BR>
候进行配置(Linux内核对PnP功能没有很好的支持，可以在驱动程序里完成这个功&nbsp;<BR>
能)。配置或协商好硬件占用的资源以后，就可以向系统申请这些资源。有些资源是&nbsp;<BR>
可以和别的设备共享的，如中断。有些是不能共享的，如IO、DMA。接下来你要初始&nbsp;<BR>
化device结构中的变量。最后，你可以让硬件正式开始工作。&nbsp;<BR>
&nbsp;<BR>
2.2.2&nbsp;打开(open)&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;open这个方法在网络设备驱动程序里是网络设备被激活的时候被调用(即设备状&nbsp;<BR>
态由down--&gt;up)。所以实际上很多在initialize中的工作可以放到这里来做。比如资&nbsp;<BR>
源的申请，硬件的激活。如果dev-&gt;open返回非0(error)，则硬件的状态还是down。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;open方法另一个作用是如果驱动程序做为一个模块被装入，则要防止模块卸载时&nbsp;<BR>
设备处于打开状态。在open方法里要调用MOD_INC_USE_COUNT宏。&nbsp;<BR>
&nbsp;<BR>
2.2.3&nbsp;关闭(stop)&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;close方法做和open相反的工作。可以释放某些资源以减少系统负担。close是在&nbsp;<BR>
设备状态由up转为down时被调用的。另外如果是做为模块装入的驱动程序，close里&nbsp;<BR>
应该调用MOD_DEC_USE_COUNT，减少设备被引用的次数，以使驱动程序可以被卸载。&nbsp;<BR>
另外close方法必须返回成功(0==success)。&nbsp;<BR>
&nbsp;<BR>
2.2.4&nbsp;发送(hard_start_xmit)&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;所有的网络设备驱动程序都必须有这个发送方法。在系统调用驱动程序的xmit&nbsp;<BR>
时，发送的数据放在一个sk_buff结构中。一般的驱动程序把数据传给硬件发出去。&nbsp;<BR>
也有一些特殊的设备比如loopback把数据组成一个接收数据再回送给系统，或者&nbsp;<BR>
dummy设备直接丢弃数据。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;如果发送成功，hard_start_xmit方法里释放sk_buff，返回0(发送成功)。如果&nbsp;<BR>
设备暂时无法处理，比如硬件忙，则返回1。这时如果dev-&gt;tbusy置为非0，则系统&nbsp;<BR>
认为硬件忙，要等到dev-&gt;tbusy置0以后才会再次发送。tbusy的置0任务一般由中断&nbsp;<BR>
完成。硬件在发送结束后产生中断，这时可以把tbusy置0，然后用mark_bh()调用通&nbsp;<BR>
知系统可以再次发送。在发送不成功的情况下，也可以不置dev-&gt;tbusy为非0，这样&nbsp;<BR>
系统会不断尝试重发。如果hard_start_xmit发送不成功，则不要释放sk_buff。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;传送下来的sk_buff中的数据已经包含硬件需要的帧头。所以在发送方法里不需&nbsp;<BR>
要再填充硬件帧头，数据可以直接提交给硬件发送。sk_buff是被锁住的(locked)，&nbsp;<BR>
确保其他程序不会存取它。&nbsp;<BR>
&nbsp;<BR>
2.2.5&nbsp;接收(reception)&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;驱动程序并不存在一个接收方法。有数据收到应该是驱动程序来通知系统的。&nbsp;<BR>
一般设备收到数据后都会产生一个中断，在中断处理程序中驱动程序申请一块&nbsp;<BR>
sk_buff(skb)，从硬件读出数据放置到申请好的缓冲区里。接下来填充sk_buff中&nbsp;<BR>
的一些信息。skb-&gt;dev&nbsp;=&nbsp;dev，判断收到帧的协议类型，填入skb-&gt;protocol(多协&nbsp;<BR>
议的支持)。把指针skb-&gt;mac.raw指向硬件数据然后丢弃硬件帧头(skb_pull)。还要&nbsp;<BR>
设置skb-&gt;pkt_type，标明第二层(链路层)数据类型。可以是以下类型：&nbsp;<BR>
&nbsp;&nbsp;PACKET_BROADCAST&nbsp;:&nbsp;链路层广播&nbsp;<BR>
&nbsp;&nbsp;PACKET_MULTICAST&nbsp;:&nbsp;链路层组播&nbsp;<BR>
&nbsp;&nbsp;PACKET_SELF&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;:&nbsp;发给自己的帧&nbsp;<BR>
&nbsp;&nbsp;PACKET_OTHERHOST&nbsp;:&nbsp;发给别人的帧(监听模式时会有这种帧)&nbsp;<BR>
&nbsp;<BR>
最后调用netif_rx()把数据传送给协议层。netif_rx()里数据放入处理队列然后返&nbsp;<BR>
回，真正的处理是在中断返回以后，这样可以减少中断时间。调用netif_rx()以后，&nbsp;<BR>
驱动程序就不能再存取数据缓冲区skb。&nbsp;<BR>
&nbsp;<BR>
2.2.6&nbsp;硬件帧头(hard_header)&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;硬件一般都会在上层数据发送之前加上自己的硬件帧头，比如以太网(Ethernet)&nbsp;<BR>
就有14字节的帧头。这个帧头是加在上层ip、ipx等数据包的前面的。驱动程序提供&nbsp;<BR>
一个hard_header方法，协议层(ip、ipx、arp等)在发送数据之前会调用这段程序。&nbsp;<BR>
硬件帧头的长度必须填在dev-&gt;hard_header_len，这样协议层回在数据之前保留好&nbsp;<BR>
硬件帧头的空间。这样hard_header程序只要调用skb_push然后正确填入硬件帧头就&nbsp;<BR>
可以了。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;在协议层调用hard_header时，传送的参数包括(2.0.xx)：数据的sk_buff，&nbsp;<BR>
device指针，protocol，目的地址(daddr)，源地址(saddr)，数据长度(len)。数据&nbsp;<BR>
长度不要使用sk_buff中的参数，因为调用hard_header时数据可能还没完全组织好。&nbsp;<BR>
saddr是NULL的话是使用缺省地址(default)。daddr是NULL表明协议层不知道硬件目&nbsp;<BR>
的地址。如果hard_header完全填好了硬件帧头，则返回添加的字节数。如果硬件帧&nbsp;<BR>
头中的信息还不完全(比如daddr为NULL，但是帧头中需要目的硬件地址。典型的情&nbsp;<BR>
况是以太网需要地址解析(arp))，则返回负字节数。hard_header返回负数的情况&nbsp;<BR>
下，协议层会做进一步的build&nbsp;header的工作。目前Linux系统里就是做arp&nbsp;<BR>
(如果hard_header返回正，dev-&gt;arp=1，表明不需要做arp，返回负，dev-&gt;arp=0，&nbsp;<BR>
做arp)。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;对hard_header的调用在每个协议层的处理程序里。如ip_output。&nbsp;<BR>
&nbsp;<BR>
2.2.7&nbsp;地址解析(xarp)&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;有些网络有硬件地址(比如Ethernet)，并且在发送硬件帧时需要知道目的硬件&nbsp;<BR>
地址。这样就需要上层协议地址(ip、ipx)和硬件地址的对应。这个对应是通过地址&nbsp;<BR>
解析完成的。需要做arp的的设备在发送之前会调用驱动程序的rebuild_header方&nbsp;<BR>
法。调用的主要参数包括指向硬件帧头的指针，协议层地址。如果驱动程序能够解&nbsp;<BR>
析硬件地址，就返回1，如果不能，返回0。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;对rebuild_header的调用在net/core/dev.c的do_dev_queue_xmit()里。&nbsp;<BR>
&nbsp;<BR>
2.2.8&nbsp;参数设置和统计数据&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;在驱动程序里还提供一些方法供系统对设备的参数进行设置和读取信息。一般&nbsp;<BR>
只有超级用户(root)权限才能对设备参数进行设置。设置方法有：&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;dev-&gt;set_mac_address()&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;当用户调用ioctl类型为SIOCSIFHWADDR时是要设置这个设备的mac地址。一般&nbsp;<BR>
对mac地址的设置没有太大意义的。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;dev-&gt;set_config()&nbsp;<BR>
&nbsp;<BR>
------------------&nbsp;Linux操作系统网络驱动程序编写&nbsp;-------------------&nbsp;<BR>
------------&nbsp;Contact&nbsp;the&nbsp;author&nbsp;by&nbsp;<A HREF="mailto:mailto:[e-mail]">mailto:[e-mail]</A>&nbsp;------&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;当用户调用ioctl时类型为SIOCSIFMAP时，系统会调用驱动程序的set_config&nbsp;<BR>
方法。用户会传递一个ifmap结构包含需要的I/O、中断等参数。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;dev-&gt;do_ioctl()&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;如果用户调用ioctl时类型在SIOCDEVPRIVATE和SIOCDEVPRIVATE+15之间，系统&nbsp;<BR>
会调用驱动程序的这个方法。一般是设置设备的专用数据。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;读取信息也是通过ioctl调用进行。除次之外驱动程序还可以提供一个&nbsp;<BR>
dev-&gt;get_stats方法，返回一个enet_statistics结构，包含发送接收的统计信息。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;ioctl的处理在net/core/dev.c的dev_ioctl()和dev_ifsioc()里。&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
2.3&nbsp;网络驱动程序中用到的数据结构&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;最重要的是网络设备的数据结构。定义在include/linux/netdevice.h里。它&nbsp;<BR>
的注释已经足够详尽。&nbsp;<BR>
struct&nbsp;device&nbsp;&nbsp;<BR>
{&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;/*&nbsp;<BR>
&nbsp;&nbsp;&nbsp;*&nbsp;This&nbsp;is&nbsp;the&nbsp;first&nbsp;field&nbsp;of&nbsp;the&nbsp;&quot;visible&quot;&nbsp;part&nbsp;of&nbsp;this&nbsp;structure&nbsp;<BR>
&nbsp;&nbsp;&nbsp;*&nbsp;(i.e.&nbsp;as&nbsp;seen&nbsp;by&nbsp;users&nbsp;in&nbsp;the&nbsp;&quot;Space.c&quot;&nbsp;file).&nbsp;&nbsp;It&nbsp;is&nbsp;the&nbsp;name&nbsp;<BR>
&nbsp;&nbsp;&nbsp;*&nbsp;the&nbsp;interface.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;*/&nbsp;<BR>
&nbsp;&nbsp;char&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*name;&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;/*&nbsp;I/O&nbsp;specific&nbsp;fields&nbsp;-&nbsp;FIXME:&nbsp;Merge&nbsp;these&nbsp;and&nbsp;struct&nbsp;ifmap&nbsp;into&nbsp;one&nbsp;*/&nbsp;<BR>
&nbsp;&nbsp;unsigned&nbsp;long&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rmem_end;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/*&nbsp;shmem&nbsp;&quot;recv&quot;&nbsp;end&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*/&nbsp;<BR>
&nbsp;&nbsp;unsigned&nbsp;long&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rmem_start;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/*&nbsp;shmem&nbsp;&quot;recv&quot;&nbsp;start&nbsp;&nbsp;&nbsp;*/&nbsp;<BR>
&nbsp;&nbsp;unsigned&nbsp;long&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mem_end;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/*&nbsp;shared&nbsp;mem&nbsp;end&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*/&nbsp;<BR>
&nbsp;&nbsp;unsigned&nbsp;long&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mem_start;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;/*&nbsp;shared&nbsp;mem&nbsp;start&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*/&nbsp;<BR>