标签:大小 全局 flag region head 64位 atom 应用程序调用 char
https://blog.csdn.net/zqixiao_09/article/details/50850004
下图描述了linux中虚拟文件系统,一般的设备文件与设备驱动程序间的函数调用关系
上图展现了一个应用程序调用字符设备驱动的过程,在设备驱动程序的设计中,一般而言,会关心 file 和 inode 这两个结构体
用户空间使用 open() 函数打开一个字符设备 fd = open("/dev/hello",O_RDWR) , 这一函数会调用两个数据结构 struct inode{...}与struct file{...} ,二者均在虚拟文件系统VFS处,下面对两个数据结构进行解析:
1、file文件结构体
(1)在设备驱动中,这是非常重要的数据结构
(2)这里的file与用户空间出现中的FILE指针式不同的,用户空间FILE是定义在C库中,从来不会出现在内核中。而struct file,确是内核中的数据结构,因此,它也不会出现在用户层程序中。
(3)file结构体指示一个已经打开的文件(设备对应设备文件),其实系统中每个打开的文件在内核空间都有一个相应的struct file结构体,它由内核在打开文件时创建,并传递给在文件上进程操作的任何函数,直至文件被关闭。如果文件被关闭,内核就会释放相应的数据结构。
(4)在内核源码中,struct file要么表示为file,或者为filp(意指“file pointer”), 注意区分一点,file指的是struct file本身,而filp是指向这个结构体的指针。
下面是几个重要成员
a -- fmode_t f_mode;
此文件模式通过FMODE_READ, FMODE_WRITE识别了文件为可读的,可写的,或者是二者。在open或ioctl函数中可能需要检查此域以确认文件的读/写权限,你不必直接去检测读或写权限,因为在进行octl等操作时内核本身就需要对其权限进行检测。
b -- loff_t f_pos;
当前读写文件的位置。为64位。如果想知道当前文件当前位置在哪,驱动可以读取这个值而不会改变其位置。对read,write来说,当其接收到一个loff_t型指针作为其最后一个参数时,他们的读写操作便作更新文件的位置,而不需要直接执行filp ->f_pos操作。而llseek方法的目的就是用于改变文件的位置。
c -- unsigned int f_flags;
文件标志,如O_RDONLY, O_NONBLOCK以及O_SYNC。在驱动中还可以检查O_NONBLOCK标志查看是否有非阻塞请求。其它的标志较少使用。特别地注意的是,读写权限的检查是使用f_mode而不是f_flog。所有的标量定义在头文件中
d -- struct file_operations *f_op;
与文件相关的各种操作。当文件需要迅速进行各种操作时,内核分配这个指针作为它实现文件打开,读,写等功能的一部分。filp->f_op 其值从未被内核保存作为下次的引用,即你可以改变与文件相关的各种操作,这种方式效率非常高。
e -- void *private_data;
在驱动调用open方法之前,open系统调用设置此指针为NULL值。你可以很自由的将其做为你自己需要的一些数据域或者不管它,如,你可以将其指向一个分配好的数据,但是你必须记得在file struct被内核销毁之前在release方法中释放这些数据的内存空间。private_data用于在系统调用期间保存各种状态信息是非常有用的。
2、inode结构体
VFS inode包含文件访问权限,属主,组,大小,生成时间,访问时间,最后修改时间等信息。它是linux管理文件系统中的最基本单位,也是文件系统连接任何子目录,文件的桥梁
内核使用inode结构体在内核内部表示一个文件。因此,它与表示一个已经打开的文件描述符的结构体(即file文件结构)是不同的, 我们可以使用多个file 文件结构表示同一个文件的多个文件描述符,但此时,所有的这些file文件结构全部都必须只能指向一个inode结构体。
inode结构体包含了一大堆文件相关的信息,但是就针对驱动代码来说,我们只要关心其中的两个域即可:
(1) dev_t i_rdev;
表示设备文件的结点,这个域实际上包含了设备号。
(2) struct cdev *i_cdev;
struct cdev是内核的一个内部结构,它是用来表示字符设备的,当inode结点指向一个字符设备文件时,此域为一个指向inode结构的指针。
3、chardevs 数组
从图中可以看出,通过数据结构 struct inode{...} 中的 i_cdev 成员可以找到cdev,而所有的字符设备都在 chrdevs 数组中
struct cdev *cdev; /* will die */
相关函数,(这些函数在上篇已经介绍过,现在回顾一下:
register_chrdev_region分配指定的设备号范围
alloc_chrdev_region动态分配失败范围
它们都主要通过调用__register_chrdev_region实现;注意,这两个函数仅仅是注册设备号。如果要将设备号和cdev(用来表示字符设备)关联起来,还要调用cdev_add
register_chrdev申请指定的设备号,并且将其注册到字符设备驱动模型中。
它所做的事情为:
a -- 注册设备号, 通过调用 __register_chrdev_region() 来实现
b -- 分配一个cdev, 通过调用 cdev_alloc() 来实现
c -- 将cdev添加到驱动模型中, 这一步将设备号和驱动关联了起来. 通过调用 cdev_add() 来实现
d -- 将第一步中创建的 struct char_device_struct 对象的 cdev 指向第二步中分配的cdev. 由于register_chrdev()是老的接口,这一步在新的接口中并不需要。
4、cdev 结构体
在 Linux 字符设备驱动开发 字符设备驱动结构 有解析。
5、文件系统中对字符设备文件的访问
下面看一下上层应用open() 调用系统调用函数的过程。
对于一个字符设备文件,其inode.i_cdev指向字符设备驱动对象cdev,如果i_cdev为Null,说明该设备文件没有被打开
由于多个设备可以共用同一个驱动程序.所以,通过字符设备的inode 中的i_devices 和 cdev中的list组成一个链表.
首先,系统调用open打开一个字符设备的时候, 通过一系列调用,最终会执行到 chrdev_open
(最终是通过调用到def_chr_fops中的.open, 而def_chr_fops.open = chrdev_open. 这一系列的调用过程,本文暂不讨论)
int chrdev_open(struct inode * inode, struct file * filp)
chrdev_open()所做的事情可以概括如下:
1. 根据设备号(inode->i_rdev), 在字符设备驱动模型中查找对应的驱动程序, 这通过kobj_lookup() 来实现, kobj_lookup()会返回对应驱动程序cdev的kobject.
2. 设置inode->i_cdev , 指向找到的cdev.
3. 将inode添加到cdev->list 的链表中.
4. 使用cdev的ops 设置file对象的f_op
5. 如果ops中定义了open方法,则调用该open方法
6. 返回执行完 chrdev_open()之后,file对象的f_op指向cdev的ops,因而之后对设备进行的read, write等操作,就会执行cdev的相应操作。
3. file、inode结构体及chardevs数组等相关知识解析
标签:大小 全局 flag region head 64位 atom 应用程序调用 char
原文地址:https://www.cnblogs.com/Ocean-Star/p/9249862.html