Linux内核及驱动学习笔记---持续更新

Linux内核及驱动学习笔记

1、内核中对于不同数据的提示

在你通读 file_operations 方法的列表时, 你会注意到不少参数包含字串 __user. 这种注解是一种文档形式, 注意, 一个指针是一个不能被直接解引用的用户空间地址. 对于正常的编译, __user 没有效果, 但是它可被外部检查软件使用来找出对用户空间地址的错误使用.

2、使用scull设备进行低内存条件测试

理论上, 给在被管理的数据项施加武断的限制总是个坏想法. 实践上, scull 可用来暂时地吃光你系统中的内存, 以便运行在低内存条件下的测试. 运行这样的测试可能会帮助你理解系统的内部. 你可以使用命令 cp /dev/zero /dev/scull0 来用 scull 吃掉所有的真实 RAM, 并且你可以使用 dd 工具来选择贝多少数据给 scull 设备.

3、read和write的错误返回规则

read 和 write 方法都在发生错误时返回一个负值. 相反, 大于或等于 0 的返回值告知调用程序有多少字节已经成功传送. 如果一些数据成功传送接着发生错误, 返回值必须是成功传送的字节数, 错误不报告直到函数下一次调用. 实现这个传统, 当然, 要求你的驱动记住错误已经发生, 以便它们可以在以后返回错误状态.

4、printk_ratelimit()

避免printk产生阻塞
由于某些原因，频繁设置循环调用某个printk的语句，将会造成CPU的拥堵，如果输入终端是慢速，就会造成拥堵，我们也不可能从这种狂刷屏幕上读取到什么有效信息，基本上就看不清。内核编程提供了一下保护机制。下面是一个测试的例子： 
1 for (i = 0 ; i < 1000; i ++){ 
2    if(printk_ratelimit()){
3        printk(KERN_DEBUG "Test for ratelimte i = %d j = %d\n",i ,++j);
4    }
5 }
6 printk(KERN_NOTICE "After Test i = %d j = %d\n",i , j);
printk_ratelimit()根据打印的频繁程度返回的一个值，根据这个值我们决定是否将debug信息打印出来。这个返回值取决于两个因素，分别定义在
/proc/sys/kernel/printk_ratelimit
/proc/sys/kernel/printk_ratelimit_burst
前者表示当这个值置为0后隔多少秒后恢复为1，即等待允许再次打印的时间（秒），后者可能和缓存队列长度有关，他表示在值为0之前，可以printk的条目数。系统缺省值为5和10，也就是在printk_ratelimit()的控制下，每秒可以有两个输出。在上面的例子，我们看到输出了10次。我想象的处理机制是，系统根据printk_ratelimit_burst的值设置一个队列长度，如果这个队列满，则值printk_ratelimit()为0，禁止新的消息加入队列，等待printk_ratelimit秒设定的时间，将 printk_ratelimit()设为1，即允许新的消息加入队列。这种方式我曾用于处理业务请求，设定允许接纳请求的频率，避免burst的出现。我猜想这里面的机制也是类似的。不管如何，这是一种看行之有效的方法。 

5、/proc

Linux提供了一个特殊的文件系统——/proc，通过建立内核与进程之间发送信息的机制，使得可以在进程运行时动态地读写内核内部的数据结构、改变内核设置。与其他文件系统的不同之处在于，/proc是处于内存之中的。
/proc中的每个文件都绑定于一个内核函数，当用户读取某个文件时，将调用指定函数读取所需信息返回给用户空间，对于内核模块调试而言，需要查看内核所处的状态等信息，此时将可以通过在/proc下创建对应文件，通过读取该文件来及时返回指定内核模块信息。大多数/proc文件是只读项。

linux内核源码中的“procfs_example.c”文件介绍了简单的/proc调试手段使用。

linux内核源码中的“.../kernel/led.c”文件介绍了简单的led状态读写使用。

6、所有的文件操作，最终都是基于FS的file_operations结构实现

static int uart_proc_open(struct inode *inode, struct file *file)
{
return single_open(file, uart_proc_show, PDE(inode)->data);
}
static const struct file_operations uart_proc_fops = {
.owner = THIS_MODULE,
.open = uart_proc_open,
.read = seq_read,
.llseek = seq_lseek,
.release = single_release,
};

7、互斥锁最好不要嵌套使用

8、驱动中关于设备的缓存处理

驱动的设备不只是提供数据的收发接口给APP，完善的实现，还需要向APP提供对于数据收发的buffer清空机制，否则会出现设备重新控制后，收发

数据异常的现象。