【Linux驱动开发】Linux应用层到驱动层大概是什么流程?

Linux应用层到驱动层大概是什么流程?

驱动运行在内核层，应用程序运行在应用层，他们之间是如何进行这么一个信息的交互过程的呢？

linux中一切皆文件的思想，每一个字符设备都是由一个文件来表示的，文件里记录着相关的硬件信息，应用层是如何更具找到这个文件并最终实现对该设备的控制的。

每一个设备都有唯一的文件进行表示，如果是同一类型的设备，那么我们需要为每一个设备都写一个驱动吗？

对于字符设备驱动的理解，从open（）函数开始，逻辑是相当清楚，

应用层透过系统调用进入内核层。同理，用户空间的数据和内核空间的数据也是不能直接进行交互的。一般也是需要使用函数进行相关的数据交换。

copy_from_user()
copy_to_user()

应用层的open()函数，通过系统调用进入内核层，sys_open(),也就是说，应用程序与虚拟文件系统VFS之间的接口是系统调用，而VFS和文件系统以及设备文件之间的接口是file_operations结构体成员函数，相应的file_operation函数就由设备驱动提供。

内核层通过相应的函数，获取到文件描述符给应用层，这个过程中，通过相应的函数获得文件操作结构体，文件操作结构体是放在inode中的，相应的 inode中存放有需要的设备号，于是进一步根据设备号从cdev表中找到对应的cdev

cdev表涉及到驱动层相关，也就是说，我们再编写驱动函数的时候，所编写的file_operations()会记录在cdev这个结构体中

---

首先需要明白，再编写好驱动后，将驱动挂载进内核以后，inode，cdev，这些结构体是已经存在的了，只有file结构体是在应用层第一次通过open()打开设备节点后才生成的。inode，cdev这些是一个驱动对应一个，而file结构是一个设备对应一个。

在应用层调用了open（）函数之后，内部做了哪些工作呢？

1. ​在虚拟文件系统 VFS 中的查找对应与字符设备对应 struct inode 节点(inode节点里面由对应的设备号)
2. 遍历散列表 cdev_map，根据 inode节点中的 cdev_t 设备号找到 cdev对象（cdev_map算驱动层做的相关事情）
3. 创建 struct file对象（系统采用一个数组来管理一个进程中的多个被打开的设备，每个文件秒速符作为数组下标标识了一个设备对象）
4. 初始化 structfile 对象，将 struct file 对象中的 file_operations 成员指向 struct cdev对象中的file_operations 成员（file->fops = cdev->fops）
5. 回调file->fops->open 函数（生成了file结构体，并返回了该文件的文件描述符

所谓应用与驱动层的交互主要是数据的传递，

• 通过系统调用open(), read(), write()等方式实现对驱动层的交互，获取驱动层数据或调用方法操作硬件。
• 通过IOCTL CMD命令方式与内核驱动层交互，从而获取驱动层数据或调用驱动层方法来操作硬件。
• 通过mmap方式来实现应用层与内核共享内存来传递数据。这种方式优点是速度快，且可以数据大块的数据量。应用程序可以通过mmap（）系统调用将驱动程序暴露的内存区域映射到自己的地址空间，从而可以直接访问硬件资源或共享内存。