Linux应用层到驱动层大约是哪些流程?
驱动运行在内核层，应用程序运行在应用层，她们之间是怎样进行如此一个信息的交互过程的呢？
linux中一切皆文件的思想，每一个字符设备都是由一个文件来表示的，文件里记录着相关的硬件信息，应用层是怎样更具找到这个文件并最终实现对该设备的控制的。
每一个设备都有惟一的文件进行表示，假如是同一类型的设备，这么我们须要为每一个设备都写一个驱动吗？
对于字符设备驱动的理解，从open（）函数开始，逻辑是相当清楚，
应用层透过系统调用步入内核层。同理，用户空间的数据和内核空间的数据也是不能直接进行交互的。通常也是须要使用函数进行相关的数据交换。
copy_from_user()
copy_to_user()
应用层的open()函数，通过系统调用步入内核层，sys_open(),也就是说，应用程序与虚拟文件系统VFS之间的插口是系统调用，而VFS和文件系统以及设备文件之间的插口是file_operations结构体成员函数linux 驱动通知应用层，相应的file_operation函数就由设备驱动提供。
内核层通过相应的函数，获取到文件描述符给应用层linux命令行和shell脚本编程宝典，这个过程中，通过相应的函数获得文件操作结构体，文件操作结构体是置于inode中的，相应的inode中储存有须要的设备号，于是进一步依据设备号从cdev表中找到对应的cdev
cdev表涉及到驱动层相关，也就是说，我们再编撰驱动函数的时侯，所编撰的file_operations()会记录在cdev这个结构体中
首先须要明白，再编撰好驱动后，将驱动挂载进内核之后，inode，cdev，这种结构体是早已存在的了，只有file结构体是在应用层第一次通过open()打开设备节点后才生成的。inode，cdev那些是一个驱动对应一个，而file结构是一个设备对应一个。
在应用层调用了open（）函数以后linux常用命令，内部做了什么工作呢？在虚拟文件系统VFS中的查找对应与字符设备对应structinode节点(inode节点上面由对应的设备号)遍历散列表cdev_map，按照inode节点中的cdev_t设备号找到cdev对象（cdev_map算驱动层做的相关事情）创建structfile对象（系统采用一个链表来管理一个进程中的多个被打开的设备，每位文件秒速符作为形参下标标示了一个设备对象）初始化structfile对象linux 驱动通知应用层，将structfile对象中的file_operations成员指向structcdev对象中的file_operations成员（file->fops=cdev->fops）反弹file->fops->open函数（生成了file结构体，并返回了该文件的文件描述符
所谓应用与驱动层的交互主要是数据的传递，
