Linux网络驱动程序编写(四)
三.编写Linux网络驱动程序中需要注意的问题
3.1 中断共享
Linux系统运行几个设备共享同一个中断。需要共享的话，在申请的时候指明共享方式。系统提供的request_irq()调用的定义：
int request_irq(unsigned int irq,
void (*handler)(int irq, void *dev_id, struct pt_regs *regs),
unsigned long irqflags,
const char * devname,
void *dev_id);
如果共享中断，irqflags设置SA_SHIRQ属性，这样就允许别的设备申请同一个中断。需要注意所有用到这个中断的设备在调用request_irq()都必须设置这个属性。系统在回调每个中断处理程序时，可以用dev_id这个参数找到相应的设备。系统在回调每个中断处理程序时，可以用dev_id这个参数找到相应的设备。一般dev_id就设为device结构本身。系统处理共享中断是用各自的dev_id参数依次调用每一个中断处理程序。
3.2 硬件发送忙时的处理
主CPU的处理能力一般比网络发送要快，所以经常会遇到系统有数据要发，但上一包数据网络设备还没发送完。因为在Linux里网络设备驱动程序一般不做数据缓存，不能发送的数据都是通知系统发送不成功，所以必须要有一个机制在硬件不忙时及时通知系统接着发送下面的数据。
一般对发送忙的处理在前面设备的发送方法(hard_start_xmit)里已经描述过，即如果发送忙，置tbusy为1。处理完发送数据后，在发送结束中断里清tbusy，同时用mark_bh()调用通知系统继续发送。
但在具体实现我的驱动程序时发现，这样的处理系统好象并不能及时地知道硬件已经空闲了，即在mark_bh()以后，系统要等一段时间才会接着发送。造成发送效率很低。2M线路只有10%不到的使用率。内核版本为2.0.35。
我最后的实现是不把tbusy置1，让系统始终认为硬件空闲，但是报告发送不成功。系统会一直尝试重发。这样处理就运行正常了。但是遍循内核源码中的网络驱动程序，似乎没有这样处理的。不知道症结在哪里。
3.3 流量控制(flow control)
网络数据的发送和接收都需要流量控制。这些控制是在系统里实现的，不需要驱动程序做工作。每个设备数据结构里都有一个参数dev->tx_queue_len，这个参数标明发送时最多缓存的数据包。在Linux系统里以太网设备(10/100Mbps)标明发送时最多缓存的数据包。在Linux系统里以太网设备(10/100Mbps)tx_queue_len一般设置为100，串行线�
相关文档：
应该说uClinux同标准Linux的最大区别就在于内存管理，同时也由于uClinux的内存管理引发了一些标准Linux所不会出现的问题。本文将把uClinux内存管理同标准Linux的那内存管理部分进行比较分析。
标准Linux使用的虚拟存储器技术
标准Linux使用虚拟存储器技术，这种技术用于提供比计算机系统中实际使用的物理内存大得多的内存 ......
root@linux ~]# tar [-cxtzjvfpPN] 文件与目录 ....
参数：
-c ：建立一个压缩文件的参数指令(create 的意思)；
-x ：解开一个压缩文件的参数指令！
-t ：查看 tarfile 里面的文件！
特别注意，在参数的下达中， c/x/t 仅能存在一个！不可同时存在！
因为不可能同时压缩与解压缩。
-z ：是否同时具有 gzip 的属性？� ......
2.4 常用的系统支持
2.4.1 内存申请和释放
include/linux/kernel.h里声明了kmalloc()和kfree()。用于在内核模式下申请和释放内存。
void *kmalloc(unsigned int len,int priority);
void kfree(void *__ptr);
与用户模式下的malloc()不同，kmalloc()申 ......
