struct file结构体
2013-08-22 10:39
597 查看
引用在 file_operations 结构体中,会看到许多函数指针所指向的函数都必须传进 struct file 结构体指针 struct file * 作为参数。struct file 结构体定义在 <linux/fs.h> 中,完整如下:
structfile{
union{
structlist_head fu_list;
structrcu_head fu_rcuhead;
}f_u;
structpath f_path;
#definef_dentry f_path.dentry
#definef_vfsmnt f_path.mnt
conststructfile_operations *f_op;
spinlock_t f_lock;
atomic_long_t f_count;
unsignedint f_flags;
fmode_t f_mode;
loff_t f_pos;
structfown_struct f_owner;
conststructcred *f_cred;
structfile_ra_state f_ra;
u64 f_version;
#ifdef CONFIG_SECURITY
void *f_security;
#endif
void *private_data;
#ifdef CONFIG_EPOLL
structlist_head f_ep_links;
#endif
structaddress_space *f_mapping;
#ifdef CONFIG_DEBUG_WRITECOUNT
unsignedlongf_mnt_write_state;
#endif
};
在设备驱动中,struct file 结构体也是一个非常重要的数据结构。注意的是,这里的 file 和应用程序中的 FILE 流指针没有什么关系,FILE 定义在 C 库中,它永远不会出现在内核代码中。
file structure 结构代表一个打开的文件(open file).(打开的文件并没有确切的指定到哪个设备驱动,实际上每个打开的文件都与内核空间中的 struct file 结构相关联)。
file structure 结构在调用open 打开一个文件时由内核创建,并会被传递给任一个对这个打开文件进行操作的函数;当所有事情都做完后,会调用 close() 关闭掉文件,此时内核释放这个数据结构。
一般地,在内核源码中,struct file 结构体的指针往往写成 filp 。
struct file 中的几个重要成员:
mode_t f_mode;
文件模式根据 FMMODE_READ 和 FMODE_WRITE 位来识别文件是否可读或可写,或是可读可写。在read() 和 write() 系统调用中,没有必要对此权限进行检查,因为内核已经在你的系统调用之前已经做了检查。如果文件没有相应的读或写权限,那么如果尝试读写都将被拒绝,驱动程序甚至对此情况毫无知觉。
loff_t f_pos;
此变量表示当前的文件读写位置。loff_t 在所有的平台上都是 64 位的变量( long long 型, gcc 专用术语)。驱动程序如果想知道当前在文件中所处位置,那么可以通过读取此变量得知,但是一般地不应直接对此进行更改。通过 llseek() 方法可以改变文件位置。
unsigned int f_flags;
这是表示如 O_RDONLY, O_NONBLOCK与 O_SYNC 这样的标志。一个驱动程序应该检查O_NONBLOCK 标志,以查看是否有非阻塞操作的请求。其它的标志用得比较少。需要注意的是,检查read/write 权限应该是通过检查 f_mode 得到而不是 f_flags 。所有的标志定义在头文件 linux/fcntl.h 中可以看到。
struct file_operations*f_op;
内核安排这个指针作为它的 open 实现的一部分,当需要分派什么操作时,会读取它。filp->f_op 因为不会被内核保存起来以在其后之用,所以我们可以改变我们对相关文件的操作,在对文件使用新的操作方法时,我们就会转移到相应调用上。
void *private_data;
在对驱动调用 open 方法之前,open() 系统调用会这个指针设置为 NULL 。用户可以自由使用这个域,或者对其忽略。可以使用这个域之想分配的数据空间,但必须记得在内核销毁 file structure 之前在 release 方法里释放掉原来分配的内存。private_data 对于系统调用之间信息的保存会显得非常有用
9014
。
struct dentry*f_dentry;
目录入口 (dentry) 结构与文件相关。一般的,除了在以 filp->f_dentry->d_inode 来访问 inode 结构时,我们不太关心 dentry 这个结构。
structfile{
union{
structlist_head fu_list;
structrcu_head fu_rcuhead;
}f_u;
structpath f_path;
#definef_dentry f_path.dentry
#definef_vfsmnt f_path.mnt
conststructfile_operations *f_op;
spinlock_t f_lock;
atomic_long_t f_count;
unsignedint f_flags;
fmode_t f_mode;
loff_t f_pos;
structfown_struct f_owner;
conststructcred *f_cred;
structfile_ra_state f_ra;
u64 f_version;
#ifdef CONFIG_SECURITY
void *f_security;
#endif
void *private_data;
#ifdef CONFIG_EPOLL
structlist_head f_ep_links;
#endif
structaddress_space *f_mapping;
#ifdef CONFIG_DEBUG_WRITECOUNT
unsignedlongf_mnt_write_state;
#endif
};
在设备驱动中,struct file 结构体也是一个非常重要的数据结构。注意的是,这里的 file 和应用程序中的 FILE 流指针没有什么关系,FILE 定义在 C 库中,它永远不会出现在内核代码中。
file structure 结构代表一个打开的文件(open file).(打开的文件并没有确切的指定到哪个设备驱动,实际上每个打开的文件都与内核空间中的 struct file 结构相关联)。
file structure 结构在调用open 打开一个文件时由内核创建,并会被传递给任一个对这个打开文件进行操作的函数;当所有事情都做完后,会调用 close() 关闭掉文件,此时内核释放这个数据结构。
一般地,在内核源码中,struct file 结构体的指针往往写成 filp 。
struct file 中的几个重要成员:
mode_t f_mode;
文件模式根据 FMMODE_READ 和 FMODE_WRITE 位来识别文件是否可读或可写,或是可读可写。在read() 和 write() 系统调用中,没有必要对此权限进行检查,因为内核已经在你的系统调用之前已经做了检查。如果文件没有相应的读或写权限,那么如果尝试读写都将被拒绝,驱动程序甚至对此情况毫无知觉。
loff_t f_pos;
此变量表示当前的文件读写位置。loff_t 在所有的平台上都是 64 位的变量( long long 型, gcc 专用术语)。驱动程序如果想知道当前在文件中所处位置,那么可以通过读取此变量得知,但是一般地不应直接对此进行更改。通过 llseek() 方法可以改变文件位置。
unsigned int f_flags;
这是表示如 O_RDONLY, O_NONBLOCK与 O_SYNC 这样的标志。一个驱动程序应该检查O_NONBLOCK 标志,以查看是否有非阻塞操作的请求。其它的标志用得比较少。需要注意的是,检查read/write 权限应该是通过检查 f_mode 得到而不是 f_flags 。所有的标志定义在头文件 linux/fcntl.h 中可以看到。
struct file_operations*f_op;
内核安排这个指针作为它的 open 实现的一部分,当需要分派什么操作时,会读取它。filp->f_op 因为不会被内核保存起来以在其后之用,所以我们可以改变我们对相关文件的操作,在对文件使用新的操作方法时,我们就会转移到相应调用上。
void *private_data;
在对驱动调用 open 方法之前,open() 系统调用会这个指针设置为 NULL 。用户可以自由使用这个域,或者对其忽略。可以使用这个域之想分配的数据空间,但必须记得在内核销毁 file structure 之前在 release 方法里释放掉原来分配的内存。private_data 对于系统调用之间信息的保存会显得非常有用
9014
。
struct dentry*f_dentry;
目录入口 (dentry) 结构与文件相关。一般的,除了在以 filp->f_dentry->d_inode 来访问 inode 结构时,我们不太关心 dentry 这个结构。
相关文章推荐
- OMAP3630 Linux I2C总线驱动分析
- Linux设备驱动开发环境的搭建
- 设备控制接口(ioctl 函数) 主要是在驱动中
- NAPI
- linux驱动入门手记
- Poll机制分析
- linux驱动相关文章
- linux字符设备驱动
- Android/Linux内核驱动相关经典书籍大合集(Linux驱动工程师必备)
- Linux USB鼠标驱动程序笔记 A
- USB OTG驱动分析(一)
- OTG驱动分析(二)
- USB On-The-Go引脚 说明
- tiny6410温度传感器详细开发步骤
- (LDD3读书记录)Chapter-2:建立和运行模块
- v4l2 编程接口 — driver
- linux驱动的入口函数module_init的加载和释放
- linux驱动学习2:运行hello模块
- Linux的温湿度传感器DHT11驱动
- linux驱动自旋锁问题