首先，个人感觉设备驱动程序与应用程序中的文件操作隔得有点远，用户空间不论是直接使用系统调用还是库函数都是通过系统调用的接口进入内核空间代码的。但是看过一个博客的分析整个过程，感觉中间层太过麻烦，必须经过虚拟文件系统才能真正到达驱动部分，对与我这个新手来说确实读不了整个过程的代码，没办法真正理解真个过程的明细。所以就从表面上看看系统调用跟驱动程序是怎样连接起来的。
就拿LDD3上面用内存模拟字符设备的例子来理解。
首先我们要动态分配一个可用的设备号，这个设备号包括主设备和从设备号。（假定是250.0，250是主，0是从，运气不好总是分到250凸-。-凸）设备号是绑定很多东西的纽带。
在得到设备号之后，我们创建了一个cdev变量，该变量在内核里用来表示一个设备，在初始化时，我们就将设备号填写到了该结构体中。也就是说我们在内核里搞到一个设备，上面写着250.0 。除了给这个设备结构体一个号码以外，还需要给它一组操作，告诉他遇到特定的命令，这个设备该怎么做。也就是file_operation
另外还有一个重点就是设备文件，在/dev/下创建，创建语法mknod name c 主 从。这个语句也透露了玄机，我们的设备文件是和一个设备结构体一一对应的。
然后就不难理解了系统调用了是怎么跟设备驱动联系起来的了，系统调用操作设备文件，根据设备文件的设备号信息，我们就到内核中去发现有该设备号的设备结构体，结构体里面有对应该系统调用的操作实体，就操作就行了。
除此之外还有两点非常重要就是传递给驱动的那两个参数，指向file的指针和指向inode的指针。inode是内核中表示文件的东西，应该是始终存在在内核中的吧，而file结构体是对应与inode表示打开的文件的。一个文件只有一个inode，但可以有多个file，驱动程序中的参数是自动又系统传值的吧。
这就是个人对设备驱动的一些理解，没看过源码，不能保证，细节部分基本没有，只为方便理解而已，希望有帮助。
进一步理解。
在更仔细阅读了LDD之后，对这个问题有了新的认识。
1.在内核中使用cdev结构体表示一个设备，内部有两个重要的成员就是设备号和file_operations这两个还是能比较充分地体现设备的信息，然后通过内部的listhead指针可以帮助设备串到链表中去，cdev_add函数所谓注册设备，也就是将节点加入到设备链表中去。
2.打开一个设备文件的时候，根据文件的设备号搜索链表，找到相应的cdev结构。然后我们就用cdev结构里的成员去填充inode和file结构。比如说inode里的设备号和cdev指针，file中的f_op
除此之外还有几句关键句：file结构由内核在open时创建，并传递给在该文件上进行操作的所有函数。
file中的f_pos当前的读写位置，读写操作会使用它们接收到的最后那个指针参数来更新这一位置。