Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1432860
  • 博文数量: 1334
  • 博客积分: 645
  • 博客等级: 上士
  • 技术积分: 5762
  • 用 户 组: 普通用户
  • 注册时间: 2012-07-25 16:56
文章分类

全部博文(1334)

文章存档

2014年(108)

2013年(1059)

2012年(169)

分类: LINUX

2013-06-05 15:08:25

    之前在研究内核的procfs时,疏漏了一个与之相关的知识点,在之后的阅读《深入Linux内核构架》的相关知识时才注意到,这就是用户空间使用sysctl函数(系统控制机制)时的内核实现原理。

    系统控制机制可以在Linux内核运行时控制内核的行为,控制参数从用户空间传输到内核中,且无须reboot。早期实现这种机制的方法是用户空间使用sysctl函数,glibc将调用sysctl系统调用来实现,然后通过传递过来的二进制码(在中的枚举定义)来找到相关的struct ctl_table

(早期结构体定义)

  1. struct ctl_table 
  2. {
  3. int ctl_name;
  4. const char *procname; /* Text ID for /proc/sys, or zero */
  5. void *data;
  6. int maxlen;
  7. mode_t mode;
  8. struct ctl_table *child;
  9. struct ctl_table *parent; /* Automatically set */
  10. proc_handler *proc_handler; /* Callback for text formatting */
  11. ctl_handler *strategy;
  12. struct proc_dir_entry *de;
  13. void *extra1;
  14. void *extra2;
  15. };

并使用其中的ctl_handler *strategy;函数来实现对内核配置的修改。

    由于原来的方案不是最优雅的方案(必须编写一个程序读取参数并使用sysctl将将要修改的参数传递给内核),并且这个系统调用非POSIX标准,所以sysctl是过时的,迟早会被抛弃。为了应对这种情况,Linuxprocfs,重排了所有的sysctl,建立了一个层次结构,最终导出到了/proc/sys/目录下。这样就可以用简单的用户空间工具来访问这些内核参数了。

    这时内核对于同一个参数的操作既有sysctl接口,也有procfs接口,可以说是冗余了。

    现在的内核中,这种机制已经改变了,即使是《深入Linux内核构架》中的描诉也已经过时了。可以说是为了对原有的sysctl系统调用兼容,内核现在对于原有的sysctl系统调用的实现做了修改,首先struct ctl_table删除了一些无用的成员:

  1. struct ctl_table 
  2. {
  3. const char *procname; /* Text ID for /proc/sys, or zero */
  4. void *data;
  5. int maxlen;
  6. mode_t mode;
  7. struct ctl_table *child;
  8. struct ctl_table *parent; /* Automatically set */
  9. proc_handler *proc_handler; /* Callback for text formatting */
  10. void *extra1;
  11. void *extra2;
  12. };

    其次,内核将通过sysctl系统调用in kernel/sysctl_binary.c传递进来二进制码通过sysctl_getname函数并利用一堆的struct bin_table结构体提供的信息转换为/proc/sys目录下的文件名路径,最终通过操作相应的procfs文件实现sysctl源码都在 kernel/sysctl_binary.c文件中,有兴趣的读者可以自己RTFSC 

综上所述,为了软件兼容性,现在的sysctl被保留,底层通过procfs实现原来的系统控制机制,如下图所示:

 

阅读(255) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~