Linux 字符设备，从应用程序调用 read() 开始，到驱动的 read() 函数，中间经历了什么过程？

Question

本人在 Linux 内核下设计过几个字符设备，从 “怎么用” 的这个角度来讲，略懂一些。
但是有一次，我被问到 “从应用程序系统调用开始，是怎么到达你的驱动函数的”？我瞬间语塞，不知道怎么回答。

于是我把这个问题转到 SegmentFault 吧，询问有无大牛能够回答，或者能够告诉我上哪里找答案、要看学习那些资料以了解这一点呢？

谢谢~~

Answer 1

如果你要讲原理，这里可以讲很多，我这里只讲一下你从代码上查找的方法，
1，在你设备注册上加打印。
2，在你的open函数中加打印，
3， 在你的调用read函数中加打印，
如果在这三个过程中，没有打印输出，则可能是没有执行到，但要排除一种可能，就是系统的打印条件比较高，你的输出优先级比较低，这个可以修改

echo 8 > /proc/sys/kernel/printk

这样就可以知道你的调用了。
原理就是上面的三个步骤。

Answer 2

1 : 可以使用 dump_stack() 查看调用的函数经过.
2 : struct cdev 是所有字符设备的基类，里面抽象出了大量字符设备共有的特性，
struct cdev {

    ....
    struct file_operations xxx;   //向vfs提供的函数集合

}

设备文件被打开，会生成 一个 Inode对象， inode 与 这个cdev有关联的关系，通过这个inode可以得到
这个cdev，得到这个cdev之后，就调用 file_operations中对应的函数了，

对应的是， 系统调用 open ----->vfs层 open -----> 字符设备提供的file_operations中的对应的函数open.