【转】在linux内核中读写文件 -- 不错
原文网址:http://blog.csdn.net/tommy_wxie/article/details/8194276
1. 序曲
在用户态,读写文件可以通过read和write这两个系统调用来完成(C库函数实际上是对系统调用的封装)。 但是,在内核态没有这样的系统调用,我们又该如何读写文件呢?
阅读linux内核源码,可以知道陷入内核执行的是实际执行的是sys_read和sys_write这两个函数,但是这两个函数没有使用EXPORT_SYMBOL导出,也就是说其他模块不能使用。
在fs/open.c中系统调用具体实现如下(内核版本2.6.34.1):
SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, int, mode)
{
long ret;
if (force_o_largefile())
flags |= O_LARGEFILE;
ret = do_sys_open(AT_FDCWD, filename, flags, mode);
/* avoid REGPARM breakage on x86: */
asmlinkage_protect(3, ret, filename, flags, mode);
return ret;
}
跟踪do_sys_open()函数,就会发现它主要使用了do_filp_open()函数该函数在fs/namei.c中,而在该文件中,filp_open函数也是调用了do_filp_open函数,并且接口和sys_open函数极为相似,调用参数也和sys_open一样,并且使用EXPORT_SYMBOL导出了,所以我们猜想该函数可以打开文件,功能和open一样。
使用同样的方法,找出了一组在内核操作文件的函数,如下:
功能 |
函数原型 |
打开文件 |
struct file *filp_open(const char *filename, int flags, int mode) |
读文件 |
ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos) |
写文件 |
ssize_t vfs_write(struct file *file, const char __user *buf, size_t count, loff_t *pos) |
关闭文件 |
int filp_close(struct file *filp, fl_owner_t id) |
2. 内核空间与用户空间
在vfs_read和vfs_write函数中,其参数buf指向的用户空间的内存地址,如果我们直接使用内核空间的指针,则会返回-EFALUT。这是因为使用的缓冲区超过了用户空间的地址范围。一般系统调用会要求你使用的缓冲区不能在内核区。这个可以用set_fs()、get_fs()来解决。
在include/asm/uaccess.h中,有如下定义:
#define MAKE_MM_SEG(s) ((mm_segment_t) { (s) })
#define KERNEL_DS MAKE_MM_SEG(0xFFFFFFFF)
#define USER_DS MAKE_MM_SEG(PAGE_OFFSET)
#define get_ds() (KERNEL_DS)
#define get_fs() (current->addr_limit)
#define set_fs(x) (current->addr_limit = (x))
如果使用,如下:
mm_segment_t fs = get_fs();
set_fs(KERNEL_FS);
//vfs_write();
vfs_read();
set_fs(fs);
详尽解释:系统调用本来是提供给用户空间的程序访问的,所以,对传递给它的参数(比如上面的buf),它默认会认为来自用户空间,在read或write()函数中,为了保护内核空间,一般会用get_fs()得到的值来和USER_DS进行比较,从而防止用户空间程序“蓄意”破坏内核空间;而现在要在内核空间使用系统调用,此时传递给read或write()的参数地址就是内核空间的地址了,在USER_DS之上(USER_DS ~ KERNEL_DS),如果不做任何其它处理,在write()函数中,会认为该地址超过了USER_DS范围,所以会认为是用户空间的“蓄意破坏”,从而不允许进一步的执行;为了解决这个问题; set_fs(KERNEL_DS);将其能访问的空间限制扩大到KERNEL_DS,这样就可以在内核顺利使用系统调用了!
在VFS的支持下,用户态进程读写任何类型的文件系统都可以使用read和write着两个系统调用,但是在linux内核中没有这样的系统调用我们如何操作文件呢?我们知道read和write在进入内核态之后,实际执行的是sys_read和sys_write,但是查看内核源代码,发现这些操作文件的函数都没有导出(使用EXPORT_SYMBOL导出),也就是说在内核模块中是不能使用的,那如何是好?
通过查看sys_open的源码我们发现,其主要使用了do_filp_open()函数,该函数在fs/namei.c中,而在改文件中,filp_open函数也是调用了do_filp_open函数,并且接口和sys_open函数极为相似,调用参数也和sys_open一样,并且使用EXPORT_SYMBOL导出了,所以我们猜想该函数可以打开文件,功能和open一样。使用同样的查找方法,我们找出了一组在内核中操作文件的函数,如下:
功能 | 函数原型 |
打开文件 | struct file *filp_open(const char *filename,int flags, int mode) |
读取文件 | ssize_t vfs_read(struct file *file,char __user *buf, size_t count, loff_t *pos) |
写文件 | ssize_t vfs_write(struct file *file,const char __user *buf,size_t count, loff_t *pos) |
关闭文件 | int filp_close(struct file *filp, fl_owner_t id) |
我们注意到在vfs_read和vfs_write函数中,其参数buf指向的用户空间的内存地址,如果我们直接使用内核空间的指针,则会返回-EFALUT。所以我们需要使用
set_fs()和get_fs()宏来改变内核对内存地址检查的处理方式,所以在内核空间对文件的读写流程为:
- mm_segment_tfs = get_fs();
- set_fs(KERNEL_FS);
- //vfs_write();
- vfs_read();
- set_fs(fs);
下面为一个在内核中对文件操作的例子:
- #include <linux/module.h>
- #include <linux/init.h>
- #include <linux/fs.h>
- #include <linux/uaccess.h>
- static charbuf[] ="你好";
- static charbuf1[10];
- int __inithello_init(void)
- {
- struct file *fp;
- mm_segment_t fs;
- loff_t pos;
- printk("hello enter/n");
- fp =filp_open("/home/niutao/kernel_file",O_RDWR | O_CREAT,0644);
- if (IS_ERR(fp)){
- printk("create file error/n");
- return -1;
- }
- fs =get_fs();
- set_fs(KERNEL_DS);
- pos =0;
- vfs_write(fp,buf, sizeof(buf), &pos);
- pos =0;
- vfs_read(fp,buf1, sizeof(buf), &pos);
- printk("read: %s/n",buf1);
- filp_close(fp,NULL);
- set_fs(fs);
- return 0;
- }
- void __exithello_exit(void)
- {
- printk("hello exit/n");
- }
- module_init(hello_init);
- module_exit(hello_exit);
- MODULE_LICENSE("GPL");
【转】在linux内核中读写文件 -- 不错的更多相关文章
- 【转】 Linux内核中读写文件数据的方法--不错
原文网址:http://blog.csdn.net/tommy_wxie/article/details/8193954 Linux内核中读写文件数据的方法 有时候需要在Linuxkernel--大 ...
- Android 怎样在linux kernel 中读写文件
前言 欢迎大家我分享和推荐好用的代码段~~ 声明 欢迎转载,但请保留文章原始出处: CSDN:http://www.csdn.net ...
- linux内核中的文件描述符(二)--socket和文件描述符
http://blog.csdn.net/ce123_zhouwei/article/details/8459730 Linux内核中的文件描述符(二)--socket和文件描述符 Kernel ve ...
- Linux内核中锁机制之内存屏障、读写自旋锁及顺序锁
在上一篇博文中笔者讨论了关于原子操作和自旋锁的相关内容,本篇博文将继续锁机制的讨论,包括内存屏障.读写自旋锁以及顺序锁的相关内容.下面首先讨论内存屏障的相关内容. 三.内存屏障 不知读者是是否记得在笔 ...
- Linux内核中锁机制之信号量、读写信号量
在上一篇博文中笔者分析了关于内存屏障.读写自旋锁以及顺序锁的相关内容,本篇博文将着重讨论有关信号量.读写信号量的内容. 六.信号量 关于信号量的内容,实际上它是与自旋锁类似的概念,只有得到信号量的进程 ...
- 大话Linux内核中锁机制之信号量、读写信号量
大话Linux内核中锁机制之信号量.读写信号量 在上一篇博文中笔者分析了关于内存屏障.读写自旋锁以及顺序锁的相关内容,本篇博文将着重讨论有关信号量.读写信号量的内容. 六.信号量 关于信号量的内容,实 ...
- 大话Linux内核中锁机制之内存屏障、读写自旋锁及顺序锁
大话Linux内核中锁机制之内存屏障.读写自旋锁及顺序锁 在上一篇博文中笔者讨论了关于原子操作和自旋锁的相关内容,本篇博文将继续锁机制的讨论,包括内存屏障.读写自旋锁以及顺序锁的相关内容.下面首先讨论 ...
- linux内核中链表代码分析---list.h头文件分析(一)【转】
转自:http://blog.chinaunix.net/uid-30254565-id-5637596.html linux内核中链表代码分析---list.h头文件分析(一) 16年2月27日17 ...
- linux内核中链表代码分析---list.h头文件分析(二)【转】
转自:http://blog.chinaunix.net/uid-30254565-id-5637598.html linux内核中链表代码分析---list.h头文件分析(二) 16年2月28日16 ...
随机推荐
- hook研究结果备忘
hook研究结果: 最近一周时间仔细研究了一下hook,也许不能称之为研究吧.顶多是让别人的思想拿过来抄袭一遍而已,写点结果也算对得起自己的这几天的苦心了. 1,首先从同事旁边听到了hook,然后看的 ...
- 3 Ways to Preload Images with CSS, JavaScript, or Ajax---reference
Preloading images is a great way to improve the user experience. When images are preloaded in the br ...
- ie浏览器下input和select的上下居中问题!!!!
在Google浏览器下的input和select标签里面的文字是根据它的高度自适应上下居中的,而ie浏览器下的input和select里面的文字就不会根据高度自适应上下居中,跟大家分享一下我的解决方法 ...
- xls和xlsx
xls XLS 就是 Microsoft Excel 工作表,是一种非常常用的电子表格格式.xls文件可以使用Microsoft Excel打开,另外微软为那些没有安装Excel的用户开发了专门的 ...
- Linux filesystem structures.
1. / – Root Every single file and directory starts from the root directory. Only root user has write ...
- Cacti以MB为单位监控流量
Cacti自带的流量监控阀值模板为“Interface – Traffic”,只能监控bytes,在添加阀值之后,报警的流量信息以bytes为单位,查看很不友好,可以通过以下方法将btyes转换成MB ...
- CompareValidator ASP控件
定义和用法 CompareValidator 控件用于将由用户输入到输入控件的值与输入到其他输入控件的值或常数值进行比较. 注释:如果输入控件为空,则不会调用任何验证函数,并且验证将成功.使用 Req ...
- 【COGS1672】难存的情缘
[题目描述] 一天机房的夜晚,无数人在MC里奋斗着... 大家都知道矿产对于MC来说是多么的重要,但由于矿越挖越少,勇士们不得不跑到更远的地方挖矿,但这样路途上就会花费相当大的时间,导致挖矿效率底下. ...
- Cloud Foundry中 JasperReports service集成
Cloud Foundry作为业界第一个开源的PaaS解决方案,正越来越多的被业界接受和认可.随着PaaS的发展,Cloud Foundry顺应潮流,充分发挥开源项目的特点,到目前为止,已经支持了大批 ...
- 解析一下rtmp协议比较难懂的地方
官方文档写的过于复杂,这里弄个简单的好入门的.chunk 分基础头,消息头,时间戳,数据部分基础头中第一个字节最高位的两个位是用来设置消息头的四种格式的,和基础头没关系,整个基础头有3个字段的长度存储 ...