Linux系统调用怎么和内核或底层驱动交互的 inode struct file
字符设备驱动原理图解
最近在看《深入Linux设备驱动程序机制》，这本书条理清晰，我从中获益良多。以前在学习内核驱动的时候就是知道怎么用，对于内部的原理了解的不是这么深入。且当时的能力有限，想了解深入也不容易。这次正好趁复习驱动原理的机会，把这本书认真学习以下。
在第二章讲解字符设备的时候，个人觉得比较有收获的主要是两个方面的知识：1、字符设备号的管理原理（char_device_struct）
2、字符设备驱动的file_operation中的函数如何与file结构体中的相应结构对应上，并被应用程序调用。
对于以上两个主要的知识点，我觉得书上的条理已经很清楚的，很容易看懂，我在这里复述就多余了。我把学到的两个知识点用图的方式总结出来，供大家参考。
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
1、字符设备号的管理原理
重点在于内核在管理时所依赖的数据结构char_device_struct以及全局的散列表chrdevs。
还有就是要知道内核对于设备号的注册与注销和驱动功能的实现是没有必然的联系的。设备号的管理是一个独立的机制，以避免驱动在使用设备号的时候发生冲突，导致驱动中的file_operation对应错误，进而出现应用层操作错误的设备。因为应用层对设备的操作就是通过设备号对应到具体的file_operation的。
2、字符设备驱动的file_operation中的函数如何与file结构体中的相应结构对应上，并被应用程序调用。
这部分的内容主要是要熟悉open函数的调用流程，驱动中的file_operation结构体就是在open函数中通过设备号与进程相关的file结构体中相应函数进行对应的。在完成了open操作之后，其他的文件操作就可以直接调用驱动file_operation中的函数了。
内核对于char_device_struct结构体的管理方式和设备号的cdev_map是类似的，都是通过主设备号作为哈希表的key来索引。
—————————————————————————————————————————————————
Linux字符设备中的两个重要结构体（file、inode）
对于Linux系统中，一般字符设备和驱动之间的函数调用关系如下图所示
上图描述了用户空间应用程序通过系统调用来调用驱动程序的过程。一般而言在驱动程序的设计中，会关系 struct file 和 struct inode 这两个结构体。
用户空间使用open()系统调用函数打开一个字符设备时（ int fd = open("dev/demo", O_RDWR) ）大致有以下过程：
- 在虚拟文件系统VFS中的查找对应与字符设备对应 struct inode节点
- 遍历字符设备列表（chardevs数组），根据inod节点中的 cdev_t设备号找到cdev对象
- 创建struct file对象（系统采用一个数组来管理一个进程中的多个被打开的设备，每个文件描述符作为数组下标标识了一个设备对象）
- 初始化struct file对象，将 struct file对象中的 file_operations成员指向 struct cdev对象中的 file_operations成员（file->fops = cdev->fops）
- 回调file->fops->open函数
一、inode结构体
VFS inode 包含文件访问权限、属主、组、大小、生成时间、访问时间、最后修改时间等信息。它是Linux 管理文件系统的最基本单位，也是文件系统连接任何子目录、文件的桥梁。
内核使用inode结构体在内核内部表示一个文件。因此，它与表示一个已经打开的文件描述符的结构体(即file 文件结构)是不同的，我们可以使用多个file 文件结构表示同一个文件的多个文件描述符，但此时，所有的这些file文件结构全部都必须只能指向一个inode结构体。
inode结构体包含了一大堆文件相关的信息，但是就针对驱动代码来说，我们只要关心其中的两个域即可：
- dev_t i_rdev; 表示设备文件的结点，这个域实际上包含了设备号。
- struct cdev *i_cdev; struct cdev是内核的一个内部结构，它是用来表示字符设备的，当inode结点指向一个字符设备文件时，此域为一个指向inode结构的指针（hy:应该是指向cdev吧）。
下面是源代码：
struct inode { struct hlist_node i_hash; struct list_head i_list; struct list_head i_sb_list; struct list_head i_dentry; unsigned long i_ino; atomic_t i_count; unsigned int i_nlink; uid_t i_uid;//inode拥有者id gid_t i_gid;//inode所属群组id dev_t i_rdev;//若是设备文件，表示记录设备的设备号！！！！！！！！ u64 i_version; loff_t i_size;//inode所代表大少
#ifdef __NEED_I_SIZE_ORDERED seqcount_t i_size_seqcount;
#endif struct timespec i_atime;//inode最近一次的存取时间 struct timespec i_mtime;//inode最近一次修改时间 struct timespec i_ctime;//inode的生成时间 unsigned int i_blkbits; blkcnt_t i_blocks; unsigned short i_bytes; umode_t i_mode; spinlock_t i_lock; struct mutex i_mutex; struct rw_semaphore i_alloc_sem; const struct inode_operations *i_op; const struct file_operations *i_fop; struct super_block *i_sb; struct file_lock *i_flock; struct address_space *i_mapping; struct address_space i_data;
#ifdef CONFIG_QUOTA struct dquot *i_dquot[MAXQUOTAS];
#endif struct list_head i_devices; union { struct pipe_inode_info *i_pipe; struct block_device *i_bdev; struct cdev *i_cdev;//若是字符设备，对应的为cdev结构 ！！！！！！！！！！！};
}; struct inode{...}inode的相关操作函数
/* 内核函数从inode中提取设备号 *//* 提取主设备号 */
static inline unsigned imajor(const struct inode *inode)
{return MAJOR(inode->i_rdev);
}
/* 提取次设备号 */
static inline unsigned iminor(const struct inode *inode)
{return MINOR(inode->i_rdev);
}二、file 文件结构体
在设备驱动中，这也是个非常重要的数据结构，必须要注意一点，这里的file与用户空间程序中的FILE指针是不同的，用户空间FILE是定义在C库中，从来不会出现在内核中。而struct file，却是内核当中的数据结构，因此，它也不会出现在用户层程序中。（hy:下下?一篇关于struct file讲错了）
file结构体指示一个已经打开的文件（设备对应于设备文件），其实系统中的每个打开的文件在内核空间都有一个相应的struct file结构体，它由内核在打开文件时创建，并传递给在文件上进行操作的任何函数，直至文件被关闭。如果文件被关闭，内核就会释放相应的数据结构。
在内核源码中，struct file要么表示为file，或者为filp(意指“file pointer”), 注意区分一点，file指的是struct file本身，而filp是指向这个结构体的指针。
下面是几个重要成员：
1、fmode_t f_mode;
此文件模式通过 FMODE_READ , FMODE_WRITE 识别了文件为可读的，可写的，或者是二者。在open或ioctl函数中可能需要检查此域以确认文件的读/写权限，你不必直接去检测读或写权限，因为在进行octl等操作时内核本身就需要对其权限进行检测。
2、 loff_t f_pos;
当前读写文件的位置。为64位。如果想知道当前文件当前位置在哪，驱动可以读取这个值而不会改变其位置。对read,write来说，当其接收到一个loff_t型指针作为其最后一个参数时，他们的读写操作便作更新文件的位置，而不需要直接执行filp ->f_pos操作。而
3、unsigned int f_flags;
文件标志，如 O_RDONLY , O_NONBLOCK 以及 O_SYNC 。在驱动中还可以检查O_NONBLOCK标志查看是否有非阻塞请求。其它的标志较少使用。特别地注意的是，读写权限的检查是使用f_mode而不是f_flog。所有的标量定义在头文件中
4、struct file_operations *f_op;
与文件相关的各种操作。当文件需要迅速进行各种操作时，内核分配这个指针作为它实现文件打开，读，写等功能的一部分。filp->f_op 其值从未被内核保存作为下次的引用，即你可以改变与文件相关的各种操作，这种方式效率非常高。
file_operation 结构体解析如下：Linux字符设备驱动file_operations
5、 void *private_data;
在驱动调用open方法之前，open系统调用设置此指针为NULL值。你可以很自由的将其做为你自己需要的一些数据域或者不管它，如，你可以将其指向一个分配好的数据，但是你必须记得在file struct被内核销毁之前在release方法中释放这些数据的内存空间。private_data用于在系统调用期间保存各种状态信息是非常有用的。
三、chardevs 数组
前面对用户层open()的分析提到，通过数据结构 struct inode{...} 中的 i_cdev 成员可以找到cdev，而所有的字符设备都在 chrdevs 数组中，chrdevs具体是什么样的呢
下面先看一下 chrdevs 的定义：
#define CHRDEV_MAJOR_HASH_SIZE 255
static DEFINE_MUTEX(chrdevs_lock);static struct char_device_struct { struct char_device_struct *next; // 结构体指针 unsigned int major; // 主设备号 unsigned int baseminor; // 次设备起始号 int minorct; // 次备号个数 char name[64]; struct cdev *cdev; /* will die */
} *chrdevs[CHRDEV_MAJOR_HASH_SIZE];// 只能挂255个字符主设备可以看到全局数组 chrdevs 包含了255(CHRDEV_MAJOR_HASH_SIZE 的值)个 struct char_device_struct的元素，每一个对应一个相应的主设备号。
如果分配了一个设备号,就会创建一个 struct char_device_struct 的对象,并将其添加到 chrdevs 中；这样,通过chrdevs数组,我们就可以知道分配了哪些设备号。
相关函数，（这些函数在上篇已经介绍过，现在回顾一下：
register_chrdev_region( ) 分配指定的设备号范围
alloc_chrdev_region( ) 动态分配设备范围
他们都主要是通过调用函数 __register_chrdev_region() 来实现的；要注意,这两个函数仅仅是注册设备号!如果要和cdev关联起来,还要调用cdev_add()。
register_chrdev( )申请指定的设备号,并且将其注册到字符设备驱动模型中.
它所做的事情为:
- 注册设备号, 通过调用 __register_chrdev_region() 来实现
- 分配一个cdev, 通过调用 cdev_alloc() 来实现
- 将cdev添加到驱动模型中, 这一步将设备号和驱动关联了起来. 通过调用 cdev_add() 来实现
- 将第一步中创建的 struct char_device_struct 对象的 cdev 指向第二步中分配的cdev. 由于register_chrdev()是老的接口,这一步在新的接口中并不需要。
四、cdev 结构体
Linux内核中，使用 struct cdev 来描述一个字符设备
五、文件系统中对字符设备文件的访问
下面看一下上层应用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的相应操作。
得到进程号：
asm/current.h
linux/sched.h
#define current get_current()
得到进程号：current->pid
得到进程名：current->comm
*************************************************************************************************************************************************
Linux设备文件三大结构：inode,file,file_operations
驱动程序就是向下控制硬件，向上提供接口，这里的向上提供的接口最终对应到应用层有三种方式：设备文件，/proc，/sys，其中最常用的就是使用设备文件，而Linux设备中用的最多的就是字符设备，本文就以字符设备为例来分析创建并打开一个字符设备的文件内部机制。
struct inode
Linux中一切皆文件，当我们在Linux中创建一个文件时，就会在相应的文件系统创建一个inode与之对应，文件实体和文件的inode是一一对应的，创建好一个inode会存在存储器中，第一次open就会将inode在内存中有一个备份，同一个文件被多次打开并不会产生多个inode，当所有被打开的文件都被close之后，inode在内存中的实例才会被释放。既然如此，当我们使用mknod(或其他方法)创建一个设备文件时，也会在文件系统中创建一个inode，这个inode和其他的inode一样，用来存储关于这个文件的静态信息(不变的信息)，包括这个设备文件对应的设备号，文件的路径以及对应的驱动对象etc。inode作为VFS四大对象之一，在驱动开发中很少需要自己进行填充，更多的是在open()方法中进行查看并根据需要填充我们的file结构。
对于不同的文件类型，inode被填充的成员内容也会有所不同，以创建字符设备为例，我们知道，add_chrdev_region其实是把一个驱动对象和一个(一组)设备号联系到一起。而创建设备文件，其实是把设备文件和设备号联系到一起。至此，这三者就被绑定在一起了。这样，内核就有能力创建一个struct inode实例了，下面是4.8.5内核中的inode。这个inode是VFS的inode，是最具体文件系统的inode的进一步封装，也是驱动开发中关心的inode，针对具体的文件系统，还有struct ext2_inode_info 等结构。
//include/linux/fs.h596 /*597 * Keep mostly read-only and often accessed (especially for598 * the RCU path lookup and 'stat' data) fields at the beginning599 * of the 'struct inode'600 */601 struct inode {602 umode_t i_mode;604 kuid_t i_uid;605 kgid_t i_gid;606 unsigned int i_flags;630 union {631 const unsigned int i_nlink;632 unsigned int __i_nlink;633 };634 dev_t i_rdev;635 loff_t i_size;636 struct timespec i_atime;637 struct timespec i_mtime;638 struct timespec i_ctime;668 union {669 struct hlist_head i_dentry;670 struct rcu_head i_rcu;671 };672 u64 i_version;673 atomic_t i_count;674 atomic_t i_dio_count;675 atomic_t i_writecount;679 const struct file_operations *i_fop; /* former ->i_op->default_file_ops */681 struct address_space i_data;682 struct list_head i_devices;683 union {684 struct pipe_inode_info *i_pipe;685 struct block_device *i_bdev;686 struct cdev *i_cdev;687 char *i_link;688 unsigned i_dir_seq;689 };702 void *i_private; /* fs or device private pointer */703 };
这里面与本文相关的成员主要有：
struct inode
--602-->i_mode表示访问权限控制
--604-->UID
--605-->GID
--606-->i_flags文件系统标志
--630-->硬链接数计数hy：--634-->设备号
--635-->i_size以字节为单位的文件大小
--636-->最后access时间
--637-->最后modify时间
--638-->最后change时间
--669-->i_dentry; //目录项链表
--673-->i_count引用计数,当引用计数变为0时，会释放inode实例
--675-->i_writecount写者计数
--679-->创建设备文件的时候i_fops填充的是def_chr_fops,blk_blk_fops,def_fifo_fops,bad_sock_fops之一,参见创建过程中调用的init_special_inode()
--683-->特殊文件类型的union,pipe,cdev,blk.link etc,i_cdev表示这个inode属于一个字符设备文件，本文中创建设备文件的时候会把与之相关的设备号的驱动对象cdev拿来填充
--702-->inode的私有数据
针对我们的问题，上面的几个成员只有struct def_chr_fops 值得一追，后面有大用：
//fs/char_dev.c
429 const struct file_operations def_chr_fops = {
430 .open = chrdev_open,
431 .llseek = noop_llseek,
432 };
struct file
Linux内核会为每一个进程维护一个文件描述符表，这个表其实就是struct file[]的索引。open()的过程其实就是根据传入的路径填充好一个file结构并将其赋值到数组中并返回其索引。下面是file的主要内容
//include/linux/fs.h877 struct file {878 union {879 struct llist_node fu_llist;880 struct rcu_head fu_rcuhead;881 } f_u;882 struct path f_path;883 struct inode *f_inode; /* cached value */884 const struct file_operations *f_op;885 886 /* 887 * Protects f_ep_links, f_flags.888 * Must not be taken from IRQ context.889 */890 spinlock_t f_lock;891 atomic_long_t f_count;892 unsigned int f_flags;893 fmode_t f_mode;894 struct mutex f_pos_lock;895 loff_t f_pos;896 struct fown_struct f_owner;897 const struct cred *f_cred;898 struct file_ra_state f_ra;f904 /* needed for tty driver, and maybe others */905 void *private_data;912 struct address_space *f_mapping;913 } __attribute__((aligned(4))); /* lest something weird decides that 2 is OK */
struct file
--882-->f_path里存储的是open传入的路径，VFS就是根据这个路径逐层找到相应的inode
--883-->f_inode里存储的是找到的inode
--884-->f_op里存储的就是驱动提供的file_operations对象，这个对象应该在第一次open()的时候被填充，具体地，应用层的open通过层层搜索会调用inode.i_fops->open()，即chrdev_open()
--891-->f_count的作用是记录对文件对象的引用计数，也即当前有多少个使用CLONE_FILES标志克隆的进程在使用该文件。典型的应用是在POSIX线程中。就像在内核中普通的引用计数模块一样，最后一个进程调用put_files_struct()来释放文件描述符。
--892-->f_flags当打开文件时指定的标志，对应系统调用open的int flags，比如驱动程序为了支持非阻塞型操作需要检查这个标志是否有O_NONBLOCK。
--893-->f_mode;对文件的读写模式，对应系统调用open的mod_t mode参数，比如O_RDWR。如果驱动程序需要这个值，可以直接读取这个字段。
--905-->private_data表示file结构的私有数据
我在Linux设备管理（二）_从cdev_add说起一文中已经分析过chrdev_open()，这里仅作概述。
//fs/chr_dev.c
348 /*
349 * Called every time a character special file is opened
350 */
351 static int chrdev_open(struct inode *inode, struct file *filp)
352 {/* 搜索cdev */...
390 replace_fops(filp, fops);
391 if (filp->f_op->open) {
392 ret = filp->f_op->open(inode, filp);
393 if (ret)
394 goto out_cdev_put;
395 } ...
402 }
可以看出，这个函数有三个任务(划重点!!!)：
*******************************hy add*******************************
用户态的open通过传入的路径，找到相应的inode（VFS） *
根据inode中的i_rdev（设备号）查找到kobj *
由kobj通过container_of查找到cdev *
将cdev中的file_operations赋值给file结构体中的f_op *
调用cdev->file_operations->open *
**********************************************************************
chrdev_open()
--352-389-->利用container_of等根据inode中的成员找到相应的cdev
--390-->用cdev.fops替换filp->f_op，即填充了一个空的struct file的f_op成员。
--392-->回调替换之后的filp->f_op->open,由于替换，这个其实就是cdev.fops
至此，我们知道了我们写的驱动中的open()在何时会被回调，这样我们就可以实现很多有意思的功能，比如，
我们可以在open中通过inode->cdev来识别具体的设备，并将其私有数据隐藏到file结构的private_data中，进而识别同一个驱动操作一类设备;
我们也可以在回调cdev.fops->open()阶段重新填充file结构的fop，进而实现同一个驱动操作不同的设备，这种思想就是内核驱动中常用的分层！
最后总结一下这些结构之间的关系：
*********************************************************************************************************************************************
学习Linux系统下驱动程序开发已有大半年时间，心中一直有个疑惑：那就是诸如open、write、read等系统调用是怎么和
内核或底层驱动建立起联系的呢？今天将自己的一些粗略的理解总结如下。
学过Linux系统下驱动程序开发的都知道，大部分的基础性的驱动操作都包括3个重要的内核数据结构，称为file_operations，file和inode。我们需要对这些结构有个基本了解才能够做大量感兴趣的事情。
1、struct file_operations是一个把字符设备驱动的操作和设备号联系在一起的纽带，是一系列指针的集合，每个被打开的文件
都对应于一系列的操作，这就是file_operations,用来执行一系列的系统调用。
2、struct file代表一个打开的文件，在执行file_operation中的open操作时被创建，这里需要注意的是与用户空间inode指针的区
别，一个在内核，而file指针在用户空间，由c库来定义。
3、struct inode被内核用来代表一个文件，注意和struct file的区别，struct inode一个是代表文件，struct file一个是代表打开的文件
struct inode 包括很重要的两个成员：
dev_t i_rdev 设备文件的设备号
struct cdev *i_cdev 代表字符设备的数据结构，struct inode结构是用来在内核内部表示文件的。同一个文件可以被打开好多次,所以可以对应很多struct file,但是只对应一个struct inode.
/* 首先你要明白struct inode *，和struct file*的意思，i结点只有一个，对于一个文件来说是唯一的，而struct file并不是唯一的，每打开一个文件就创建一个 struct file结点，对应一个文件描述符。文件描述符可能是0，1，2，3。。。*/
应用层调用open函数,首先会发出open系统调用,然后进入内核,调用sys_open函数,打开文件系统中的/dev/fs文件,这个文件要么你是用mknod建立的,要么就直接在内核中用devfs方式来建立的,无论你用哪种方式建立,最终都会读取其文件属性,如果发现其是设备文件,就会调用LINUX内核中的设备管理部分,根据其属性的主设备号(在建立设备节点时已经把主设备号写入文件属性当中,如果你仔细看过mknod的用法就明白了),查找内核中相关联的file_operations,最终找到你的test_open函数。
所以说 "在LINUX中设备即是文件 ",设备驱动首先会走文件系统这一条路(比如最先的 "/dev/fs "),然后根据设备文件的属性最终找到相关联的file_operations,从而调用你的设备驱动例程.假如发现这个文件不是设备文件而只是磁盘文件,就继续走文件系统,高速缓冲与磁盘调度这一条路了。
sys_open（内核函数）就直接到VFS层了，open过程中会得到设备文件的inode（通过传进来的文件名参数），（参考我的博文里关于inode介绍），其file_operations结构体会赋给file结构体（含此成员fops）中相应成员，且当open方法不为空调用之。不过特殊文件
的inode里的file_operations都是一样的，比如字符设备文件inode之file_operations只定义了一个open方法，open方法根据inode中的设备
号在已注册的字符设备驱动中查找cdev，这个cdev里的fops才是驱动提供的。它会赋给file结构体中相应成员（file_operations结构体）
（覆盖了之前的一次赋值），其open方法不为空则调用之。
现在我们就演示一下用户使用write函数将数据写到设备里面这个过程到底是怎么实现的：
1，insmod驱动程序。驱动程序申请设备名和主设备号，这些可以在/proc/devieces中获得。
2，从/proc/devices中获得主设备号，并使用mknod命令建立设备节点文件。这是通过主设备号将设备节点文件和设备驱动程序联系在
一起。设备节点文件中的file属性中指明了驱动程序中fops方法实现的函数指针。
3，用户程序使用open打开设备节点文件，这时操作系统内核知道该驱动程序工作了，就调用fops方法中的open函数进行相应的工作。
open方法一般返回的是文件标示符，实际上并不是直接对它进行操作的，而是由操作系统的系统调用在背后工作。
4，当用户使用write函数操作设备文件时，操作系统调用sys_write函数，该函数首先通过文件标示符得到设备节点文件对应的inode指针
和flip指针。inode指针中有设备号信息，能够告诉操作系统应该使用哪一个设备驱动程序，flip指针中有fops信息，可以告诉操作系统相应
的fops方法函数在那里可以找到。
5，然后这时sys_write才会调用驱动程序中的write方法来对设备进行写的操作。
其中1-3都是在用户空间进行的，4-5是在核心空间进行的。用户的write函数和操作系统的write函数通过系统调用sys_write联系在了一起。
注意：
总的来说：设备文件通过设备号绑定了设备驱动，fops绑定了应用层的write和驱动层的write。当应用层写一个设备文件的时候，系统
找到对应的设备驱动，再通过fops找到对应的驱动write函数。
int open(const char *pathname, int flags, mode_t mode); --系统调用
||
\/
long sys_open(const char __user *filename, int flags, int mode) -- fs/open.c
/*对应内核中的open接口函数*/
||
\/
long do_sys_open(int dfd, const char __user *filename, int flags, int mode) --fs/open.c
/*用户空间的filename被拷贝到内核空间，获取当前可用的文件描述符*/
||
\/
static struct file *do_filp_open(int dfd, const char *filename, int flags, int mode) --fs/open.c
||
\/
int open_namei(int dfd, const char *pathname, int flag,
int mode, struct nameidata *nd)
/*获取该文件对应的nameidata结构.该函数执行完毕，接着调用下面函数。这两个函数是顺序被do_filp_open调用*/
||
\/
struct file *nameidata_to_filp(struct nameidata *nd, int flags) --fs/open.c
/*将nameidata 结构转换为打开的struct file结构*/
||
\/
static struct file *__dentry_open(struct dentry *dentry, struct vfsmount *mnt,
int flags, struct file *f,
int (*open)(struct inode *, struct file *)) --fs/open.c
||
\/
f->f_op = fops_get(inode->i_fop); --fs/open.c
/*这里将系统调用中需要对应打开文件对应到内核中的file_operations结构体获取到，然后根据其函数指针就可以找到该结构体中对
该种文件操作的所有方法。scull对应的结构体是在scull_init的时候向内核注册的。
||
\/
open = f->f_op->open;
open(inode, f); --fs/open.c
/*以上两行代码分别完成了open系统调用时执行实际文件对应内核的open方法，即scull_open。
*************************************************************************************************************************************************
struct inode 和 struct file
1、struct inode──字符设备驱动相关的重要结构介绍
内核中用inode结构表示具体的文件，而用file结构表示打开的文件描述符。Linux2.6.27内核中，inode结构体具体定义如下：
struct inode {
struct hlist_node i_hash;
struct list_head i_list;
struct list_head i_sb_list;
struct list_head i_dentry;
unsigned long i_ino;
atomic_t i_count;
unsigned int i_nlink;
uid_t i_uid;
gid_t i_gid;
dev_t i_rdev; //该成员表示设备文件的inode结构，它包含了真正的设备编号。
u64 i_version;
loff_t i_size;
#ifdef __NEED_I_SIZE_ORDERED
seqcount_t i_size_seqcount;
#endif
struct timespec i_atime;
struct timespec i_mtime;
struct timespec i_ctime;
unsigned int i_blkbits;
blkcnt_t i_blocks;
unsigned short i_bytes;
umode_t i_mode;
spinlock_t i_lock; /* i_blocks, i_bytes, maybe i_size */
struct mutex i_mutex;
struct rw_semaphore i_alloc_sem;
const struct inode_operations *i_op;
const struct file_operations *i_fop; /* former ->i_op->default_file_ops */
struct super_block *i_sb;
struct file_lock *i_flock;
struct address_space *i_mapping;
struct address_space i_data;
#ifdef CONFIG_QUOTA
struct dquot *i_dquot[MAXQUOTAS];
#endif
struct list_head i_devices;
union {
struct pipe_inode_info *i_pipe;
struct block_device *i_bdev;
struct cdev *i_cdev; //该成员表示字符设备的内核的内部结构。当inode指向一个字符设备文件时，该成员包含了指向struct cdev结构的指针，其中cdev结构是字符设备结构体。
};
int i_cindex;
__u32 i_generation;
#ifdef CONFIG_DNOTIFY
unsigned long i_dnotify_mask; /* Directory notify events */
struct dnotify_struct *i_dnotify; /* for directory notifications */
#endif
#ifdef CONFIG_INOTIFY
struct list_head inotify_watches; /* watches on this inode */
struct mutex inotify_mutex; /* protects the watches list */
#endif
unsigned long i_state;
unsigned long dirtied_when; /* jiffies of first dirtying */
unsigned int i_flags;
atomic_t i_writecount;
#ifdef CONFIG_SECURITY
void *i_security;
#endif
void *i_private; /* fs or device private pointer */
};
2、struct file ──字符设备驱动相关重要结构
文件结构 代表一个打开的文件描述符，它不是专门给驱动程序使用的，系统中每一个打开的文件在内核中都有一个关联的struct file。它由内核在open时创建，并传递给在文件上操作的任何函数，直到最后关闭。当文件的所有实例都关闭之后，内核释放这个数据结构。
struct file {
/*
* fu_list becomes invalid after file_free is called and queued via
* fu_rcuhead for RCU freeing
*/
union {
struct list_head fu_list;
struct rcu_head fu_rcuhead;
} f_u;
struct path f_path;
#define f_dentry f_path.dentry //该成员是对应的目录结构 。
#define f_vfsmnt f_path.mnt
const struct file_operations *f_op; //该操作是定义文件关联的操作的。内核在执行open时对这个指针赋值。
atomic_long_t f_count;
unsigned int f_flags; //该成员是文件标志。
mode_t f_mode;
loff_t f_pos;
struct fown_struct f_owner;
unsigned int f_uid, f_gid;
struct file_ra_state f_ra;
u64 f_version;
#ifdef CONFIG_SECURITY
void *f_security;
#endif
/* needed for tty driver, and maybe others */
void *private_data;//该成员是系统调用时保存状态信息非常有用的资源。
#ifdef CONFIG_EPOLL
/* Used by fs/eventpoll.c to link all the hooks to this file */
struct list_head f_ep_links;
spinlock_t f_ep_lock;
#endif /* #ifdef CONFIG_EPOLL */
struct address_space *f_mapping;
#ifdef CONFIG_DEBUG_WRITECOUNT
unsigned long f_mnt_write_state;
#endif
};
----------------------------------------------------------------------------
file结构体和inode结构体
（1）struct file结构体定义在include/linux/fs.h中定义。文件结构体代表一个打开的文件，系统中的每个打开的文件在内核空间都有一个关联的 struct file。它由内核在打开文件时创建，并传递给在文件上进行操作的任何函数。在文件的所有实例都关闭后，内核释放这个数据结构。在内核创建和驱动源码中，struct file的指针通常被命名为file或filp。如下所示：
struct file {
union {
struct list_head fu_list; 文件对象链表指针linux/include/linux/list.h
struct rcu_head fu_rcuhead; RCU(Read-Copy Update)是Linux 2.6内核中新的锁机制
} f_u;
struct path f_path; 包含dentry和mnt两个成员，用于确定文件路径
#define f_dentry f_path.dentry f_path的成员之一，当前文件的dentry结构
#define f_vfsmnt f_path.mnt 表示当前文件所在文件系统的挂载根目录
const struct file_operations *f_op; 与该文件相关联的操作函数
atomic_t f_count; 文件的引用计数（有多少进程打开该文件）
unsigned int f_flags; 对应于open时指定的flag
mode_t f_mode; 读写模式：open的mod_t mode参数
off_t f_pos; 该文件在当前进程中的文件偏移量
struct fown_struct f_owner; 该结构的作用是通过信号进行I/O时间通知的数据。
unsigned int f_uid, f_gid; 文件所有者id，所有者组id
struct file_ra_state f_ra; 在linux/include/linux/fs.h中定义，文件预读相关
unsigned long f_version;
#ifdef CONFIG_SECURITY
void *f_security;
#endif
/* needed for tty driver, and maybe others */
void *private_data;
#ifdef CONFIG_EPOLL
/* Used by fs/eventpoll.c to link all the hooks to this file */
struct list_head f_ep_links;
spinlock_t f_ep_lock;
#endif /* #ifdef CONFIG_EPOLL */
struct address_space *f_mapping;
};
（2）struct dentry
dentry 的中文名称是目录项，是Linux文件系统中某个索引节点(inode)的链接。这个索引节点可以是文件，也可以是目录。inode（可理解为ext2 inode）对应于物理磁盘上的具体对象，dentry是一个内存实体，其中的d_inode成员指向对应的inode。也就是说，一个inode可以在运行的时候链接多个dentry，而d_count记录了这个链接的数量。
struct dentry {
atomic_t d_count; 目录项对象使用计数器,可以有未使用态,使用态和负状态
unsigned int d_flags; 目录项标志
struct inode * d_inode; 与文件名关联的索引节点
struct dentry * d_parent; 父目录的目录项对象
struct list_head d_hash; 散列表表项的指针
struct list_head d_lru; 未使用链表的指针
struct list_head d_child; 父目录中目录项对象的链表的指针
struct list_head d_subdirs;对目录而言，表示子目录目录项对象的链表
struct list_head d_alias; 相关索引节点（别名）的链表
int d_mounted; 对于安装点而言，表示被安装文件系统根项
struct qstr d_name; 文件名
unsigned long d_time; /* used by d_revalidate */
struct dentry_operations *d_op; 目录项方法
struct super_block * d_sb; 文件的超级块对象
vunsigned long d_vfs_flags;
void * d_fsdata;与文件系统相关的数据
unsigned char d_iname [DNAME_INLINE_LEN]; 存放短文件名
};
（3）索引节点对象由inode结构体表示，定义文件在linux/fs.h中。
struct inode {
struct hlist_node i_hash; 哈希表
struct list_head i_list; 索引节点链表
struct list_head i_dentry; 目录项链表
unsigned long i_ino; 节点号
atomic_t i_count; 引用记数
umode_t i_mode; 访问权限控制
unsigned int i_nlink; 硬链接数
uid_t i_uid; 使用者id
gid_t i_gid; 使用者id组
kdev_t i_rdev; 实设备标识符
loff_t i_size; 以字节为单位的文件大小
struct timespec i_atime; 最后访问时间
struct timespec i_mtime; 最后修改(modify)时间
struct timespec i_ctime; 最后改变(change)时间
unsigned int i_blkbits; 以位为单位的块大小
unsigned long i_blksize; 以字节为单位的块大小
unsigned long i_version; 版本号
unsigned long i_blocks; 文件的块数
unsigned short i_bytes; 使用的字节数
spinlock_t i_lock; 自旋锁
struct rw_semaphore i_alloc_sem; 索引节点信号量
struct inode_operations *i_op; 索引节点操作表
struct file_operations *i_fop; 默认的索引节点操作
struct super_block *i_sb; 相关的超级块
struct file_lock *i_flock; 文件锁链表
struct address_space *i_mapping; 相关的地址映射
struct address_space i_data; 设备地址映射
struct dquot *i_dquot[MAXQUOTAS];节点的磁盘限额
struct list_head i_devices; 块设备链表
struct pipe_inode_info *i_pipe; 管道信息
struct block_device *i_bdev; 块设备驱动
unsigned long i_dnotify_mask;目录通知掩码
struct dnotify_struct *i_dnotify; 目录通知
unsigned long i_state; 状态标志
unsigned long dirtied_when;首次修改时间
unsigned int i_flags; 文件系统标志
unsigned char i_sock; 套接字
atomic_t i_writecount; 写者记数
void *i_security; 安全模块
__u32 i_generation; 索引节点版本号
union {
void *generic_ip;文件特殊信息
} u;
};
inode 译成中文就是索引节点。每个存储设备或存储设备的分区（存储设备是硬盘、软盘、U盘 ... ... ）被格式化为文件系统后，应该有两部份，一部份是inode，另一部份是Block，Block是用来存储数据用的。而inode呢，就是用来存储这些数据的信息，这些信息包括文件大小、属主、归属的用户组、读写权限等。inode为每个文件进行信息索引，所以就有了inode的数值。操作系统根据指令，能通过inode值最快的找到相对应的文件。
做个比喻，比如一本书，存储设备或分区就相当于这本书，Block相当于书中的每一页，inode 就相当于这本书前面的目录，一本书有很多的内容，如果想查找某部份的内容，我们可以先查目录，通过目录能最快的找到我们想要看的内容。
当我们用ls 查看某个目录或文件时，如果加上-i 参数，就可以看到inode节点了；比如ls -li lsfile.sh ，最前面的数值就是inode信息
Linux系统调用怎么和内核或底层驱动交互的 inode struct file相关推荐
- qt如和调用linux底层驱动_擅长复杂硬件体系设计，多核系统设计，以及基于RTOS或者Linux，QT等进行相关底层驱动。...
双向可控硅在使用时,其触发限流电阻的阻值和封装应该怎么选取? (1)首先我们在进行TRIAC其驱动电路设计的时候,我们一般不直接进行驱动,而是通过DIAC或者Photo-TRIAC即光学的双向可控硅配 ...
- linux底层驱动内核,Linux底层驱动开发需要学习哪些内容
Linux底层驱动开发需要学习哪些内容想必这是很多学习Linux的朋友十分头疼的问题,今天就让我来告诉大家我们到底该学习哪些内容呢? 1. 要会一些硬件知识,比如Arm接口编程 2. 学会写简单的ma ...
- 基于Linux操作系统的底层驱动技术
5.3 基于Linux操作系统的底层驱动技术 这里的底层驱动是指Linux下的底层设备驱动,这些驱动通常都是加载在内核态的,可以提供给上层用户态的应用程序访问底层设备的能力.也就是说,上层应用程序通过 ...
- Linux底层驱动编译原理 ，编译过程 以及 装载（树莓派）
一.用户支配驱动工作的过程 上层应用调用open,read,write等标准C库函数 触发软中断:0x80 ,由用户态进入到内核态,发生系统调用 系统调用syscall,文件子系统会调用相应的syso ...
- 操作系统课程设计：Linux系统调用/基于模块的文件系统/Linux驱动/统计Linux系统缺页的次数 整合
目录 一.可选题目 题目1:新增Linux系统调用 题目2:实现基于模块的文件系统 题目3:新增Linux驱动程序 题目4:统计Linux系统缺页的次数 二.操作顺序 附录:参考资料 题1 题2 题3 ...
- 正点原子Linux开发板 spi内核驱动 0.96寸ips屏教程
正点原子Linux开发板 spi内核驱动 0.96寸ips屏教程 首先选择模块 设备树配置 spi驱动程序(用的spi_driver) app 最近做下底层SPI驱动来驱动IPS屏,本来想实现这种效果 ...
- linux下的系统调用函数到内核函数的追踪
Original from: http://blog.chinaunix.net/uid-28458801-id-3468966.html 使用的 glibc : glibc-2.17 使用的 lin ...
- linux 内核块设备驱动,你了解Linux 块设备驱动？
1 什么是Ramdisk Ramdisk是一种模拟磁盘,其数据实际上是存储在RAM中,它使用一部分内存空间来模拟出一个磁盘设备,并以块设备的方式来组织和访问这片内存.对于用户来说可以把Ramdisk与 ...
- linux 深入理解I2C内核驱动
系列文章 I.MX6ULL 手册查找使用方法 实战点亮LED(寄存器版) I.MX6ULL 手册查找使用方法 实战点亮LED(固件库版本) linux 字符设备驱动实战 linux LED设备驱动文件 ...
- Linux用户态与内核态通信的几种方式（待完善）
文章目录 1. 内核启动参数 2.模块参数与sysfs 3.sysctl 4.系统调用 5.netlink 6. procfs(/proc) 7.seq_file 8.debugfs 9.relayf ...
最新文章
- 放弃MyBatis！我选择 JDBCTemplate！
- 云知声CEO黄伟：AI对产业的驱动不仅是创新更是颠覆
- bootstrap 点击加号 表格_bootstrap中的输入组按钮，点击加号加1，减1子
- linux安装软件命令1003无标题,linux系统安装OFED（infiniband）
- Node+Vue实现对数据的增删改查
- .NET工程师的书单
- css限制字体三行_讲道理，仅3行核心css代码的rate评分组件，我被自己秀到头皮发麻...
- matlab时域转复频域,信号与系统实验(MATLAB版)实验15连续系统的复频域分析.ppt...
- 长沙学院计算机系课程表,长沙交通学院研究生200—200学年度第学期课程表.doc...
- 让解析器可以快速处理词法单元之间的空格
- oracle 判断为空赋一个值_求高手帮忙，oracle查出的值为null，怎么赋初始值？
- lae界面开发工具入门介绍之一新建工程篇
- cocos2d-x android 直接加载下载到sd的zip里的资源文件(一)
- （Java实习生）每日10道面试题打卡——JavaWeb篇
- mysql innodb文件存储_MySQL数据库和InnoDB存储引擎文件
- CSS在线字体库，外部字体的引用方法@font-face
- 计算机安全技术相关实例,计算机安全技术TOOLS教程课件5.14 实例：无线网络安全配置.doc...
- 建网站，买域名和虚拟空间总共要多少钱？
- 数据中台产品经理-读书笔记3
- 怎么在pc端浏览器调试移动端页面