linuxproc接口

尽管像本文这样短小的一篇文章无法详细介绍 /proc 的所有用法&＃xff0c;但是它依然对这两种用法进行了展示&＃xff0c;从而可以让我们体会一下 /proc 是多么强大。清单 1 是对 /proc 中部分元素进行一次交互查询的结果。它显示的是 /proc 文件系统的根目录中的内容。注意&＃xff0c;在左边是一系列数字编号的文件。每个实际上都是一个目录&＃xff0c;表示系统中的一个进程。由于在 GNU/Linux 中创建的第一个进程是 init 进程&＃xff0c;因此它的 process-id 为 1。然后对这个目录执行一个 ls 命令&＃xff0c;这会显示很多文件。每个文件都提供了有关这个特殊进程的详细信息。例如&＃xff0c;要查看 init 的 command-line 项的内容&＃xff0c;只需对 cmdline 文件执行 cat 命令。

/proc 中另外一些有趣的文件有&＃xff1a;cpuinfo&＃xff0c;它标识了处理器的类型和速度&＃xff1b;pci&＃xff0c;显示在 PCI 总线上找到的设备&＃xff1b;modules&＃xff0c;标识了当前加载到内核中的模块。

清单 2 展示了对 /proc 中的一个虚拟文件进行读写的过程。这个例子首先检查内核的 TCP/IP 栈中的 IP 转发的目前设置&＃xff0c;然后再启用这种功能。

另外&＃xff0c;我们还可以使用 sysctl 来配置这些内核条目。有关这个问题的更多信息&＃xff0c;请参阅 参考资料 一节的内容。

顺便说一下&＃xff0c;/proc 文件系统并不是 GNU/Linux 系统中的惟一一个虚拟文件系统。在这种系统上&＃xff0c;sysfs 是一个与 /proc 类似的文件系统&＃xff0c;但是它的组织更好&＃xff08;从 /proc 中学习了很多教训&＃xff09;。不过 /proc 已经确立了自己的地位&＃xff0c;因此即使 sysfs 与 /proc 相比有一些优点&＃xff0c;/proc 也依然会存在。还有一个 debugfs 文件系统&＃xff0c;不过&＃xff08;顾名思义&＃xff09;它提供的更多是调试接口。debugfs 的一个优点是它将一个值导出给用户空间非常简单&＃xff08;实际上这不过是一个调用而已&＃xff09;。

内核模块简介

可加载内核模块&＃xff08;LKM&＃xff09;是用来展示 /proc 文件系统的一种简单方法&＃xff0c;这是因为这是一种用来动态地向 Linux 内核添加或删除代码的新方法。LKM 也是 Linux 内核中为设备驱动程序和文件系统使用的一种流行机制。

如果您曾经重新编译过 Linux 内核&＃xff0c;就可能会发现在内核的配置过程中&＃xff0c;有很多设备驱动程序和其他内核元素都被编译成了模块。如果一个驱动程序被直接编译到了内核中&＃xff0c;那么即使这个驱动程序没有运行&＃xff0c;它的代码和静态数据也会占据一部分空间。但是如果这个驱动程序被编译成一个模块&＃xff0c;就只有在需要内存并将其加载到内核时才会真正占用内存空间。有趣的是&＃xff0c;对于 LKM 来说&＃xff0c;我们不会注意到有什么性能方面的差异&＃xff0c;因此这对于创建一个适应于自己环境的内核来说是一种功能强大的手段&＃xff0c;这样可以根据可用硬件和连接的设备来加载对应的模块。

下面是一个简单的 LKM&＃xff0c;可以帮助您理解它与在 Linux 内核中看到的标准&＃xff08;非动态可加载的&＃xff09;代码之间的区别。清单 3 给出了一个最简单的 LKM。&＃xff08;可以从本文的 下载 一节中下载这个代码&＃xff09;。

清单 3 包括了必须的模块头&＃xff08;它定义了模块的 API、类型和宏&＃xff09;。然后使用 MODULE_LICENSE 定义了这个模块使用的许可证。此处&＃xff0c;我们定义的是 GPL&＃xff0c;从而防止会污染到内核。

清单 3 然后又定义了这个模块的 init 和 cleanup 函数。my_module_init 函数是在加载这个模块时被调用的&＃xff0c;它用来进行一些初始化方面的工作。my_module_cleanup 函数是在卸载这个模块时被调用的&＃xff0c;它用来释放内存并清除这个模块的踪迹。注意此处 printk 的用法&＃xff1a;这是内核的 printf 函数。KERN_INFO 符号是一个字符串&＃xff0c;可以用来对进入内核回环缓冲区的信息进行过滤&＃xff08;非常类似于 syslog&＃xff09;。

最后&＃xff0c;清单 3 使用 module_init 和 module_exit 宏声明了入口函数和出口函数。这样我们就可以按照自己的意愿来对这个模块的 init 和 cleanup 函数进行命名了&＃xff0c;不过我们最终要告诉内核维护函数就是这些函数。

清单 3 尽管非常简单&＃xff0c;但它却是一个真正的 LKM。现在让我们对其进行编译并在一个 2.6 版本的内核上进行测试。2.6 版本的内核为内核模块的编译引入了一种新方法&＃xff0c;我发现这种方法比原来的方法简单了很多。对于文件 simple-lkm.c&＃xff0c;我们可以创建一个 makefile&＃xff0c;其惟一内容如下&＃xff1a;

要编译 LKM&＃xff0c;请使用 make 命令&＃xff0c;如清单 4 所示。

结果会生成一个 simple-lkm.ko 文件。这个新的命名约定可以帮助将这些内核对象&＃xff08;LKM&＃xff09;与标准对象区分开来。现在可以加载或卸载这个模块了&＃xff0c;然后可以查看它的输出。要加载这个模块&＃xff0c;请使用 insmod 命令&＃xff1b;反之&＃xff0c;要卸载这个模块&＃xff0c;请使用 rmmod 命令。lsmod 可以显示当前加载的 LKM&＃xff08;参见清单 5&＃xff09;。

注意&＃xff0c;内核的输出进到了内核回环缓冲区中&＃xff0c;而不是打印到 stdout 上&＃xff0c;这是因为 stdout 是进程特有的环境。要查看内核回环缓冲区中的消息&＃xff0c;可以使用 dmesg 工具&＃xff08;或者通过 /proc 本身使用 cat /proc/kmsg 命令&＃xff09;。清单 6 给出了 dmesg 显示的最后几条消息。

可以在内核输出中看到这个模块的消息。现在让我们暂时离开这个简单的例子&＃xff0c;来看几个可以用来开发有用 LKM 的内核 API。

回页首

集成到 /proc 文件系统中

内核程序员可以使用的标准 API&＃xff0c;LKM 程序员也可以使用。LKM 甚至可以导出内核使用的新变量和函数。有关 API 的完整介绍已经超出了本文的范围&＃xff0c;因此我们在这里只是简单地介绍后面在展示一个更有用的 LKM 时所使用的几个元素。

创建并删除 /proc 项

要在 /proc 文件系统中创建一个虚拟文件&＃xff0c;请使用 create_proc_entry 函数。这个函数可以接收一个文件名、一组权限和这个文件在 /proc 文件系统中出现的位置。create_proc_entry 的返回值是一个 proc_dir_entry 指针&＃xff08;或者为 NULL&＃xff0c;说明在 create 时发生了错误&＃xff09;。然后就可以使用这个返回的指针来配置这个虚拟文件的其他参数&＃xff0c;例如在对该文件执行读操作时应该调用的函数。create_proc_entry 的原型和 proc_dir_entry 结构中的一部分如清单 7 所示。

稍后我们就可以看到如何使用 read_proc 和 write_proc 命令来插入对这个虚拟文件进行读写的函数。

要从 /proc 中删除一个文件&＃xff0c;可以使用 remove_proc_entry 函数。要使用这个函数&＃xff0c;我们需要提供文件名字符串&＃xff0c;以及这个文件在 /proc 文件系统中的位置&＃xff08;parent&＃xff09;。这个函数原型如清单 7 所示。

parent 参数可以为 NULL&＃xff08;表示 /proc 根目录&＃xff09;&＃xff0c;也可以是很多其他值&＃xff0c;这取决于我们希望将这个文件放到什么地方。表 1 列出了可以使用的其他一些父 proc_dir_entry&＃xff0c;以及它们在这个文件系统中的位置。

回调函数

我们可以使用 write_proc 函数向 /proc 中写入一项。这个函数的原型如下&＃xff1a;

filp 参数实际上是一个打开文件结构&＃xff08;我们可以忽略这个参数&＃xff09;。buff 参数是传递给您的字符串数据。缓冲区地址实际上是一个用户空间的缓冲区&＃xff0c;因此我们不能直接读取它。len 参数定义了在 buff 中有多少数据要被写入。data 参数是一个指向私有数据的指针&＃xff08;参见 清单 7&＃xff09;。在这个模块中&＃xff0c;我们声明了一个这种类型的函数来处理到达的数据。

Linux 提供了一组 API 来在用户空间和内核空间之间移动数据。对于 write_proc 的情况来说&＃xff0c;我们使用了 copy_from_user 函数来维护用户空间的数据。

读回调函数

我们可以使用 read_proc 函数从一个 /proc 项中读取数据&＃xff08;从内核空间到用户空间&＃xff09;。这个函数的原型如下&＃xff1a;

page 参数是这些数据写入到的位置&＃xff0c;其中 count 定义了可以写入的最大字符数。在返回多页数据&＃xff08;通常一页是 4KB&＃xff09;时&＃xff0c;我们需要使用 start 和 off 参数。当所有数据全部写入之后&＃xff0c;就需要设置 eof&＃xff08;文件结束参数&＃xff09;。与 write 类似&＃xff0c;data 表示的也是私有数据。此处提供的 page 缓冲区在内核空间中。因此&＃xff0c;我们可以直接写入&＃xff0c;而不用调用 copy_to_user。

其他有用的函数

我们还可以使用 proc_mkdir、symlinks 以及 proc_symlink 在 /proc 文件系统中创建目录。对于只需要一个 read 函数的简单 /proc 项来说&＃xff0c;可以使用 create_proc_read_entry&＃xff0c;这会创建一个 /proc 项&＃xff0c;并在一个调用中对 read_proc 函数进行初始化。这些函数的原型如清单 8 所示。

回页首

通过 /proc 文件系统实现财富分发

下面是一个可以支持读写的 LKM。这个简单的程序提供了一个财富甜点分发。在加载这个模块之后&＃xff0c;用户就可以使用 echo 命令向其中导入文本财富&＃xff0c;然后再使用 cat 命令逐一读出。

清单 9 给出了基本的模块函数和变量。init 函数&＃xff08;init_fortune_module&＃xff09;负责使用 vmalloc 来为这个点心罐分配空间&＃xff0c;然后使用 memset 将其全部清零。使用所分配并已经清空的 COOKIE_pot 内存&＃xff0c;我们在 /proc 中创建了一个 proc_dir_entry 项&＃xff0c;并将其称为 fortune。当 proc_entry 成功创建之后&＃xff0c;对自己的本地变量和 proc_entry 结构进行了初始化。我们加载了 /proc read 和 write 函数&＃xff08;如清单 9 和清单 10 所示&＃xff09;&＃xff0c;并确定这个模块的所有者。cleanup 函数简单地从 /proc 文件系统中删除这一项&＃xff0c;然后释放 COOKIE_pot 所占据的内存。

COOKIE_pot 是一个固定大小&＃xff08;4KB&＃xff09;的页&＃xff0c;它使用两个索引进行管理。第一个是 COOKIE_index&＃xff0c;标识了要将下一个 COOKIE 写到哪里去。变量 next_fortune 标识了下一个 COOKIE 应该从哪里读取以便进行输出。在所有的 fortune 项都读取之后&＃xff0c;我们简单地回到了 next_fortune。

向这个罐中新写入一个 COOKIE 非常简单&＃xff08;如清单 10 所示&＃xff09;。使用这个写入 COOKIE 的长度&＃xff0c;我们可以检查是否有这么多空间可用。如果没有&＃xff0c;就返回 -ENOSPC&＃xff0c;它会返回给用户空间。否则&＃xff0c;就说明空间存在&＃xff0c;我们使用 copy_from_user 将用户缓冲区中的数据直接拷贝到 COOKIE_pot 中。然后增大 COOKIE_index&＃xff08;基于用户缓冲区的长度&＃xff09;并使用 NULL 来结束这个字符串。最后&＃xff0c;返回实际写入 COOKIE_pot 的字符的个数&＃xff0c;它会返回到用户进程。

对 fortune 进行读取也非常简单&＃xff0c;如清单 11 所示。由于我们刚才写入数据的缓冲区&＃xff08;page&＃xff09;已经在内核空间中了&＃xff0c;因此可以直接对其进行操作&＃xff0c;并使用 sprintf 来写入下一个 fortune。如果 next_fortune 索引大于 COOKIE_index&＃xff08;要写入的下一个位置&＃xff09;&＃xff0c;那么我们就将 next_fortune 返回为 0&＃xff0c;这是第一个 fortune 的索引。在将这个 fortune 写入用户缓冲区之后&＃xff0c;在 next_fortune 索引上增加刚才写入的 fortune 的长度。这样就变成了下一个可用 fortune 的索引。这个 fortune 的长度会被返回并传递给用户。

从这个简单的例子中&＃xff0c;我们可以看出通过 /proc 文件系统与内核进行通信实际上是件非常简单的事情。现在让我们来看一下这个 fortune 模块的用法&＃xff08;参见清单 12&＃xff09;。

/proc 虚拟文件系统可以广泛地用来报告内核的信息&＃xff0c;也可以用来进行动态配置。我们会发现它对于驱动程序和模块编程来说都是非常完整的。

例如&＃xff1a;

1&＃xff0c;/proc/cmdline 的例子

static int cmdline_proc_show(struct seq_file *m, void *v)
{
seq_printf(m, "%s/n", saved_command_line);
return 0;
}

static int cmdline_proc_open(struct inode *inode, struct file *file)
{
return single_open(file, cmdline_proc_show, NULL);
}

static const struct file_operations cmdline_proc_fops &＃61; {
.open&＃61; cmdline_proc_open,
.read&＃61; seq_read,
.llseek&＃61; seq_lseek,
.release&＃61; single_release,
};

static int __init proc_cmdline_init(void)
{
proc_create("cmdline", 0, NULL, &cmdline_proc_fops);
return 0;
}

2&＃xff0c; 在proc目录产生pdc子目录和led&＃xff0c;lcd文件

static int __init led_create_procfs(void)
{
struct proc_dir_entry *proc_pdc_root &＃61; NULL;
struct proc_dir_entry *ent;

if (led_type &＃61;&＃61; -1) return -1;

proc_pdc_root &＃61; proc_mkdir("pdc", 0);
if (!proc_pdc_root) return -1;
proc_pdc_root->owner &＃61; THIS_MODULE;
ent &＃61; create_proc_entry("led", S_IFREG|S_IRUGO|S_IWUSR, proc_pdc_root);
if (!ent) return -1;
ent->data &＃61; (void *)LED_NOLCD; /* LED */
ent->read_proc &＃61; led_proc_read;
ent->write_proc &＃61; led_proc_write;
ent->owner &＃61; THIS_MODULE;

if (led_type &＃61;&＃61; LED_HASLCD)
{
ent &＃61; create_proc_entry("lcd", S_IFREG|S_IRUGO|S_IWUSR, proc_pdc_root);
if (!ent) return -1;
ent->data &＃61; (void *)LED_HASLCD; /* LCD */
ent->read_proc &＃61; led_proc_read;
ent->write_proc &＃61; led_proc_write;
ent->owner &＃61; THIS_MODULE;
}

return 0;
}

其实自己一直感觉linux系统中的proc接口很好用&＃xff0c;不需要写应用程序就可以测试那些驱动接口&＃xff0c;只需要在超级终端中敲入命令&＃xff0c;爽。今天把一直以来寄存在其他程序中的proc接口移植到自己的程序中&＃xff0c;自己写了个proc接口&＃xff0c;分享一下。