android底层驱动学习之DebugFS的用法，以及对file_operations的进一步理解

DebugFS，顾名思义，是一种用于内核调试的虚拟文件系统，内核开发者通过debugfs和用户空间交换数据。类似的虚拟文件系统还有procfs和sysfs等，这几种虚拟文件系统都并不实际存储在硬盘上，而是Linux内核运行起来后才建立起来。

那如何交换数据呢？下面请看：

1.首先先看定义：

static const struct file_operations __fops = {\
.owner = THIS_MODULE, \
.open = XXXXX _open,\
.release = XXXXX_release,\
.read = XXXXX_read,\
.write = simple_attr_write, \
.llseek = generic_file_llseek, \
};

2. 每个文件都对应一个file_operations ，对于DebugFS来说，我们可以通过以下方法来创建对应file_operations 结构的debug_addr_fops结构体指针

temp = debugfs_create_file("addr", S_IRUSR | S_IWUSR, data->dir, data,&debug_addr_fops);

这样就可以在data->dir指向的文件夹下生成一个文件，当我们采用open，read或者在shell下cat 、echo时相当于就是调用.open、.read也就是

XXXXX _open和yXXXX_read函数，这样应该明白了内核与用户空间信息的交换。

3. 通常情况下，最常用的内核调试手段是printk。但printk并不是所有情况都好用，比如打印的数据可能过多，我们真正关心的数据在大量的输出里不是那么一目了然；或者我们在调试时可能需要修改某些内核变量，这种情况下printk就无能为力，而如果为了修改某个值重新编译内核或者驱动又过于低效，此时就需要一个临时的文件系统可以把我们需要关心的数据映射到用户空间。在过去，procfs可以实现这个目的，到了2.6时代，新引入的sysfs也同样可以实现，但不论是procfs或是sysfs，用它们来实现某些debug的需求，似乎偏离了它们创建的本意。比如procfs，其目的是反映进程的状态信息；而sysfs主要用于Linux设备模型。不论是procfs或是sysfs的接口应该保持相对稳定，因为用户态程序很可能会依赖它们。当然，如果我们只是临时借用procfs或者sysfs来作debug之用，在代码发布之前将相关调试代码删除也无不可。但如果相关的调试借口要在相当长的一段时间内存在于内核之中，就不太适合放在procfs和sysfs里了。故此，debugfs应运而生。

4. 我么知道在kernel里面许多大型模块都使用了debugfs调试，像qualcomm display中就使用了许多，可以打印mdp等内部各个参数的值，对调试大型模块起到了至关重要作用。对于模块出现问题使用debugfs来调试是非常好的，前提是模块中有debugfs的加入。我们通常都是在出现问题之后才添加log来跟踪，这样效率很慢。

5. 最后总结下：通过在模块中添加debugfs来分析问题很有效率。