调试文件系统:实现Linux内核空间与用户空间的通信
最编程
2024-08-13 21:28:41
...
一、debugfs文件系统简介
debugfs虚拟文件系统是一种内核空间与用户空间的接口,基于libfs库实现,专用于开发人员调试,便于向用户空间导出内核空间数据(当然,反方向也可以)。debugfs在linux内核版本2.6.10引入,作者是Greg Kroah-Hartman。
与procfs和sysfs不同,前者主要提供进程信息(当然后来又加入设备、内存、网络等信息,比较杂乱),后者主要提供设备信息,且有一个文件提供一个值的“规则”,是Linux通用设备模型的影射。debugfs没有类似的限制,开发者可以放入任何信息。
二、debugfs的使用
说明:函数接口请参见:http://docs.huihoo.com/doxygen/linux/kernel/3.7/fs_2debugfs_2file_8c.html#ad5e6fa7f4a3de8d751a7fff4d99e59f3
1. 挂载debugfs文件系统
要使用debugfs,需要在内核编译配置中配置CONFIG_DEBUG_FS选项,一般的发行版都会默认编译进了内核,并且将其自动挂载默认的目录(/sys/kernel/debug),可通过以下命令查看:
也可手动挂载到其它位置:
$ mkdir /debugfs $ mount -t debugfs none /debugfs
2. 利用debugfs导出基本数据类型的变量
debugfs可以将内核中基本整数类型的变量导出为单个文件,在用户空间中可以直接对其读写(如使用cat、echo命令),只要权限允许即可。支持的类型有:u8, u16, u32, u64, size_t和 bool。其中bool类型在内核中要定义为u32类型,在用户空间中对应的文件内容则显示为Y或N。示例代码如下:
static struct dentry *root_d = debugfs_create_dir("exam_debugfs", NULL); //在debugfs根目录下创建新目录exam_debugfs,然会新建目录的目录项指针 static u8 var8; debugfs_create_u8("var-u8", 0664, root_d, &var8); //在exam_debugfs中创建变量var8对应的文件,名为var-u8,权限为0664 static u32 varbool; debugfs_create_bool("var-bool", 0664, root_d, &varbool); //bool变量
3. 利用debugfs导出数据块(只读)
debugfs提供的debugfs_create_blob函数可导出数据块,示例代码如下:
char buf[] = "Hello debugfs!\n"; b.data = buf; b.size = strlen(buf) + 1; debugfs_create_blob("blob", 0644, root_d, &b); // blob is readonly, even if 0644没错,debugfs提供的debugfs_blob_wrapper结构所导出的数据块只能读取,不能修改。
4. 利用debugfs导出u32数组(只读)
debugfs提供的debugfs_create_u32_array函数可导出内核中u32类型的数组。示例代码如下:
u32 arr[] = {1,2,3,4,5}; debugfs_create_u32_array("array", 0664, root_d, arr, sizeof(arr)/sizeof(u32));
5. 实现可读写数据块的导出
实现并不难,只需实现struct file_operations的open、write、read方法即可。然后调用debugfs提供的debugfs_create_file即可。该方法的原型如下:
struct dentry* debugfs_create_file ( const char * name, umode_t mode, struct dentry * parent, void * data, // 传入的data指针会被赋值给新建文件对应inode的i_private字段 const struct file_operations * fops )下面,仿照struct debugfs_blob_wrapper的实现,实现struct my_blob_wrapper和my_blob_wrapper_ops,提供可读写的“blob”:
/** 自定义可读写blob **/ struct my_blob_wrapper{ void *data; unsigned long size; // data缓冲区长度 }; static int my_blob_wrapper_open(struct inode *inode, struct file *filp) { filp->private_data = inode->i_private; // inode->i_private被设置为debugfs_create_file传入的data参数 return 0; } static ssize_t my_blob_wrapper_read(struct file *filp, char __user *user_buf, size_t count, loff_t *ppos) { struct my_blob_wrapper *blob = filp->private_data; return simple_read_from_buffer(user_buf, count, ppos, blob->data, blob->size);//此函数有libfs提供,与下面逻辑等价 // if (*ppos >= blob->size) { // return 0; // } // if (*ppos + count > blob->size) { // count = blob->size - *ppos; // } // if (copy_to_user(user_buf, blob->data + *ppos, count) != 0) { // return -EFAULT; // } // *ppos += count; // return count; } static ssize_t my_blob_wrapper_write(struct file *filp, const char __user *user_buf, size_t count, loff_t *ppos) { struct my_blob_wrapper *blob = filp->private_data; return simple_write_to_buffer(blob->data, blob->size, ppos, user_buf, count);//此函数由libfs提供,与下面逻辑等价 // if (*ppos >= blob->size) { // return 0; // } // if (*ppos + count > blob->size) { // count = blob->size - *ppos; // } // if (copy_from_user(blob->data + *ppos, user_buf, count) != 0) { // return -EFAULT; // } // *ppos += count; // return count; } static struct file_operations my_blob_wrapper_ops = { .owner = THIS_MODULE, .open = my_blob_wrapper_open, .read = my_blob_wrapper_read, .write = my_blob_wrapper_write, .llseek = default_llseek,//VFS提供 }; struct dentry *my_create_blob(const char *name, umode_t mode, struct dentry *parent, struct my_blob_wrapper *blob) { return debugfs_create_file(name, mode, parent, blob, &my_blob_wrapper_ops); } /* done */
6. 注意:
① 在debugfs中创建的文件和目录在模块退出时,并不会自动删除,可调用debugfs_remove_recursive删除整个目录,或调用debugfs_remove删除单个文件。
② u32_array在用户空间文件中显示为空格隔开的元素
③ debugfs_create_x{8,16,32,64}与debugfs_create_u{8,16,32,64}的不同在于前者显示为16进制,后者显示为10进制
三、debugfs示例完整代码
#include <linux/module.h> #include <linux/debugfs.h> #include <linux/fs.h> // for libfs #include <asm-generic/uaccess.h> /** 自定义可读写blob **/ struct my_blob_wrapper{ void *data; unsigned long size; }; static int my_blob_wrapper_open(struct inode *inode, struct file *filp) { filp->private_data = inode->i_private; return 0; } static ssize_t my_blob_wrapper_read(struct file *filp, char __user *user_buf, size_t count, loff_t *ppos) { struct my_blob_wrapper *blob = filp->private_data; return simple_read_from_buffer(user_buf, count, ppos, blob->data, blob->size); // from libfs } static ssize_t my_blob_wrapper_write(struct file *filp, const char __user *user_buf, size_t count, loff_t *ppos) { struct my_blob_wrapper *blob = filp->private_data; return simple_write_to_buffer(blob->data, blob->size, ppos, user_buf, count); } static struct file_operations my_blob_wrapper_ops = { .owner = THIS_MODULE, .open = my_blob_wrapper_open, .read = my_blob_wrapper_read, .write = my_blob_wrapper_write, .llseek = default_llseek, // from vfs }; /* 接口函数 */ struct dentry *my_create_blob(const char *name, umode_t mode, struct dentry *parent, struct my_blob_wrapper *blob) { return debugfs_create_file(name, mode, parent, blob, &my_blob_wrapper_ops); } /** my_clob implementation end **/ static struct dentry *root_d; static u8 var8; static u16 var16; static u32 var32; static u32 varbool; static char buf[] = "Hello debugfs!\n"; static struct debugfs_blob_wrapper b; static struct my_blob_wrapper b2; static u32 arr[] = {1,2,3,4,5}; int __init mod_init(void) { printk(KERN_INFO "exam_debugfs: initialing...\n"); root_d = debugfs_create_dir("exam_debugfs", NULL); if (!root_d) { printk(KERN_INFO "exam_debugfs: error create root dir\n"); return 1; } /* u{8,16,32}, bool */ debugfs_create_u8("var-u8", 0664, root_d, &var8); debugfs_create_u16("var-u16", 0664, root_d, &var16); debugfs_create_u32("var-u32", 0664, root_d, &var32); debugfs_create_bool("var-bool", 0664, root_d, &varbool); /* u32_array */ debugfs_create_u32_array("array", 0664, root_d, arr, sizeof(arr)/sizeof(u32)); /* blob_wrapper */ b.data = buf; b.size = strlen(buf) + 1; debugfs_create_blob("blob", 0644, root_d, &b); // blob is readonly, even if 0644 /* my_blob_wrapper */ b2.data = buf; b2.size = strlen(buf) + 1; my_create_blob("myblob", 0644, root_d, &b2); return 0; } void __exit mod_exit(void) { debugfs_remove_recursive(root_d); printk(KERN_INFO "exam_debugfs: exiting...\n"); } module_init(mod_init); module_exit(mod_exit); MODULE_LICENSE("GPL"); MODULE_DESCRIPTION("a demo for debugfs"); MODULE_AUTHOR("rsljdkt");
四、补充:debugfs bool的实现
static ssize_t read_file_bool(struct file *file, char __user *user_buf, size_t count, loff_t *ppos) { char buf[3]; u32 *val = file->private_data; if (*val) buf[0] = 'Y'; else buf[0] = 'N'; buf[1] = '\n'; buf[2] = 0x00; return simple_read_from_buffer(user_buf, count, ppos, buf, 2); } static ssize_t write_file_bool(struct file *file, const char __user *user_buf, size_t count, loff_t *ppos) { char buf[32]; size_t buf_size; bool bv; u32 *val = file->private_data; buf_size = min(count, (sizeof(buf)-1)); if (copy_from_user(buf, user_buf, buf_size)) return -EFAULT; if (strtobool(buf, &bv) == 0) *val = bv; return count; }
参考:
Debugfs http://en.wikipedia.org/wiki/Debugfs
Function Documentation http://docs.huihoo.com/doxygen/linux/kernel/3.7/fs_2debugfs_2file_8c.html#ad5e6fa7f4a3de8d751a7fff4d99e59f3
Linux内核里的DebugFS http://www.cnblogs.com/wwang/archive/2011/01/17/1937609.html
header file: http://lxr.free-electrons.com/source/include/linux/debugfs.h
推荐阅读
-
调试文件系统:实现Linux内核空间与用户空间的通信
-
windows下进程间通信的(13种方法)-摘 要 本文讨论了进程间通信与应用程序间通信的含义及相应的实现技术,并对这些技术的原理、特性等进行了深入的分析和比较。 ---- 关键词 信号 管道 消息队列 共享存储段 信号灯 远程过程调用 Socket套接字 MQSeries 1 引言 ---- 进程间通信的主要目的是实现同一计算机系统内部的相互协作的进程之间的数据共享与信息交换,由于这些进程处于同一软件和硬件环境下,利用操作系统提供的的编程接口,用户可以方便地在程序中实现这种通信;应用程序间通信的主要目的是实现不同计算机系统中的相互协作的应用程序之间的数据共享与信息交换,由于应用程序分别运行在不同计算机系统中,它们之间要通过网络之间的协议才能实现数据共享与信息交换。进程间通信和应用程序间通信及相应的实现技术有许多相同之处,也各有自己的特色。即使是同一类型的通信也有多种的实现方法,以适应不同情况的需要。 ---- 为了充分认识和掌握这两种通信及相应的实现技术,本文将就以下几个方面对这两种通信进行深入的讨论:问题的由来、解决问题的策略和方法、每种方法的工作原理和实现、每种实现方法的特点和适用的范围等。 2 进程间的通信及其实现技术 ---- 用户提交给计算机的任务最终都是通过一个个的进程来完成的。在一组并发进程中的任何两个进程之间,如果都不存在公共变量,则称该组进程为不相交的。在不相交的进程组中,每个进程都独立于其它进程,它的运行环境与顺序程序一样,而且它的运行环境也不为别的进程所改变。运行的结果是确定的,不会发生与时间相关的错误。 ---- 但是,在实际中,并发进程的各个进程之间并不是完全互相独立的,它们之间往往存在着相互制约的关系。进程之间的相互制约关系表现为两种方式: ---- (1) 间接相互制约:共享CPU ---- (2) 直接相互制约:竞争和协作 ---- 竞争——进程对共享资源的竞争。为保证进程互斥地访问共享资源,各进程必须互斥地进入各自的临界段。 ---- 协作——进程之间交换数据。为完成一个共同任务而同时运行的一组进程称为同组进程,它们之间必须交换数据,以达到协作完成任务的目的,交换数据可以通知对方可以做某事或者委托对方做某事。 ---- 共享CPU问题由操作系统的进程调度来实现,进程间的竞争和协作由进程间的通信来完成。进程间的通信一般由操作系统提供编程接口,由程序员在程序中实现。UNIX在这个方面可以说最具特色,它提供了一整套进程间的数据共享与信息交换的处理方法——进程通信机制(IPC)。因此,我们就以UNIX为例来分析进程间通信的各种实现技术。 ---- 在UNIX中,文件(File)、信号(Signal)、无名管道(Unnamed Pipes)、有名管道(FIFOs)是传统IPC功能;新的IPC功能包括消息队列(Message queues)、共享存储段(Shared memory segment)和信号灯(Semapores)。 ---- (1) 信号 ---- 信号机制是UNIX为进程中断处理而设置的。它只是一组预定义的值,因此不能用于信息交换,仅用于进程中断控制。例如在发生浮点错、非法内存访问、执行无效指令、某些按键(如ctrl-c、del等)等都会产生一个信号,操作系统就会调用有关的系统调用或用户定义的处理过程来处理。 ---- 信号处理的系统调用是signal,调用形式是: ---- signal(signalno,action) ---- 其中,signalno是规定信号编号的值,action指明当特定的信号发生时所执行的动作。 ---- (2) 无名管道和有名管道 ---- 无名管道实际上是内存中的一个临时存储区,它由系统安全控制,并且独立于创建它的进程的内存区。管道对数据采用先进先出方式管理,并严格按顺序操作,例如不能对管道进行搜索,管道中的信息只能读一次。 ---- 无名管道只能用于两个相互协作的进程之间的通信,并且访问无名管道的进程必须有共同的祖先。 ---- 系统提供了许多标准管道库函数,如: pipe——打开一个可以读写的管道; close——关闭相应的管道; read——从管道中读取字符; write——向管道中写入字符; ---- 有名管道的操作和无名管道类似,不同的地方在于使用有名管道的进程不需要具有共同的祖先,其它进程,只要知道该管道的名字,就可以访问它。管道非常适合进程之间快速交换信息。 ---- (3) 消息队列(MQ) ---- 消息队列是内存中独立于生成它的进程的一段存储区,一旦创建消息队列,任何进程,只要具有正确的的访问权限,都可以访问消息队列,消息队列非常适合于在进程间交换短信息。 ---- 消息队列的每条消息由类型编号来分类,这样接收进程可以选择读取特定的消息类型——这一点与管道不同。消息队列在创建后将一直存在,直到使用msgctl系统调用或iqcrm -q命令删除它为止。 ---- 系统提供了许多有关创建、使用和管理消息队列的系统调用,如: ---- int msgget(key,flag)——创建一个具有flag权限的MQ及其相应的结构,并返回一个唯一的正整数msqid(MQ的标识符); ---- int msgsnd(msqid,msgp,msgsz,msgtyp,flag)——向队列中发送信息; ---- int msgrcv(msqid,cmd,buf)——从队列中接收信息; ---- int msgctl(msqid,cmd,buf)——对MQ的控制操作; ---- (4) 共享存储段(SM) ---- 共享存储段是主存的一部分,它由一个或多个独立的进程共享。各进程的数据段与共享存储段相关联,对每个进程来说,共享存储段有不同的虚拟地址。系统提供的有关SM的系统调用有: ---- int shmget(key,size,flag)——创建大小为size的SM段,其相应的数据结构名为key,并返回共享内存区的标识符shmid; ---- char shmat(shmid,address,flag)——将当前进程数据段的地址赋给shmget所返回的名为shmid的SM段; ---- int shmdr(address)——从进程地址空间删除SM段; ---- int shmctl (shmid,cmd,buf)——对SM的控制操作; ---- SM的大小只受主存限制,SM段的访问及进程间的信息交换可以通过同步读写来完成。同步通常由信号灯来实现。SM非常适合进程之间大量数据的共享。 ---- (5) 信号灯 ---- 在UNIX中,信号灯是一组进程共享的数据结构,当几个进程竞争同一资源时(文件、共享内存或消息队列等),它们的操作便由信号灯来同步,以防止互相干扰。 ---- 信号灯保证了某一时刻只有一个进程访问某一临界资源,所有请求该资源的其它进程都将被挂起,一旦该资源得到释放,系统才允许其它进程访问该资源。信号灯通常配对使用,以便实现资源的加锁和解锁。 ---- 进程间通信的实现技术的特点是:操作系统提供实现机制和编程接口,由用户在程序中实现,保证进程间可以进行快速的信息交换和大量数据的共享。但是,上述方式主要适合在同一台计算机系统内部的进程之间的通信。 3 应用程序间的通信及其实现技术 ---- 同进程之间的相互制约一样,不同的应用程序之间也存在竞争和协作的关系。UNIX操作系统也提供一些可用于应用程序之间实现数据共享与信息交换的编程接口,程序员可以通过自己编程来实现。如远程过程调用和基于TCP/IP协议的套接字(Socket)编程。但是,相对普通程序员来说,它们涉及的技术比较深,编程也比较复杂,实现起来困难较大。 ---- 于是,一种新的技术应运而生——通过将有关通信的细节完全掩盖在某个独立软件内部,即底层的通讯工作和相应的维护管理工作由该软件内部来实现,用户只需要将通信任务提交给该软件去完成,而不必理会它的具体工作过程——这就是所谓的中间件技术。 ---- 我们在这里分别讨论这三种常用的应用程序间通信的实现技术——远程过程调用、会话编程技术和MQSeries消息队列技术。其中远程过程调用和会话编程属于比较低级的方式,程序员参与的程度较深,而MQSeries消息队列则属于比较高级的方式,即中间件方式,程序员参与的程度较浅。 ---- 4.1 远程过程调用(RPC)