Linux内注释第11章 可调内核参数.docVIP

第11章 可调内核参数 遵循Unix的BSD 4.4版本所倡导的风格，Linux提供sysctl系统调用以便在系统运行过程中对它所拥有的某些特性进行检查和重新配置，它并不需要你编辑内核的源代码、重新编译，然后重启机器。这是对早期Unix版本的一个十分重要的改进，在早期版本里调整系统经常是令人头痛的琐碎事务。Linux把可以被检查和重新配置的系统特性有机地组织成了几个种类：常规内核参数、虚拟内存参数、网络参数，等等。 同样的特性也可以从一个不同的接口进行访问：/proc文件系统。（因为它真正的是系统的一个透视区（window）而不只是真实文件的一个容器，所以/proc是一个“伪的文件系统”，不过那是一个蹩脚的词汇，而且无论如何这个区别在此并不重要。）每种可调内核参数在/proc/sys下都表现为一个子目录，而每个单独的可调系统参数由某个子目录下的一个文件来代表。这些子目录可能又包含一级子目录，它们仍然含有更多的代表可调系统参数的文件和子目录，等等，但是这种嵌套级数从来都不会很深。 /proc/sys绕过了通常的sysctl接口：一个可调内核参数的值可以简单的通过读取相应的文件来得到，通过写入该文件可以设置它的值。普通Unix文件系统的许可被应用于这些文件，以便对能够对它们进行读写的用户进行控制。大多数文件对所有用户是可读的但是只对root（根用户）可写，不过也有例外：比如，/proc/sys/vm下的文件（虚拟内存参数）只能被root来读写。如果不使用/proc/sys，检查和调整系统将需要编写程序并使用必须的参数调用sysctl——虽然不是任务艰巨的劳动，可是也比不上使用/proc/sys来得方便。 struct ctl_table 18274：这是本章涉及的代码中所使用的一个主要数据结构。struct ctl_tables通常是由数组聚合起来的，每个这样的数组对应于/proc/sys下某处一个单独目录里的条目。（依我之见，称它为struct ctl_table_entry可能更好。）root_table（30328行）以及在它之后的数组通过struct ctl_table的child指针连结节点而形成了一个数组树（child将在下边的列表中介绍）。注意所有这些都是ctl_table的数组，它只是为struct ctl_table进行typedef；18184行完成这项工作。 图11.1示意出了数组树间的关系。这幅图显示了由root_table形成的树的一小部分以及它所指向的树。 struct ctl_table具有如下成员： ctl_name——是唯一标识表项的一个整数——在它所在的数组中是唯一的；这个数字在不同的数组中是可以重用的。数组的任何一项都已经存在这样一个唯一的数字了——就是它的数组下标——可是这个数字不能被用于该目的，因为我们想要维护不同内核发布版本中的二进制兼容性。与某内核版本里一个数组项相关联的可调内核参数可能不会出现在将来的内核版本里，所以假如参数是被它们的数组下标定义的，对数组里废弃项目位置的重新使用将使还没有在新内核版本下编译过的程序变得混乱。随着时间的推移，为了向后兼容而带上的只浪费空间但没有作用的元素项将会使数组变得乱七八糟。相反的，这种方法只会“浪费”整数，而整数资源却无疑是非常丰富的。（另一方面，查找也会更慢，因为一个简单的数组下标还不足以满足这种方法。） 要注意的是这与有系统调用的情形相当类似：每个系统调用都与一个在系统调用表里唯一标识它位置的数字相关联。但是在这种情况里使用了一个不同的解决办法，可能由于速度在此并不重要的缘故。 图11.1 ctl_table 树的一部分 struct ctl_table具有如下成员： ctl_name——是唯一标识表项的一个整数——在它所在的数组中是唯一的；这个数字在不同的数组中是可以重用的。数组的任何一项都已经存在这样一个唯一的数字了——就是它的数组下标——可是这个数字不能被用于该目的，因为我们想要维护不同内核发布版本中的二进制兼容性。与某内核版本里一个数组项相关联的可调内核参数可能不会出现在将来的内核版本里，所以假如参数是被它们的数组下标定义的，对数组里废弃项目位置的重新使用将使还没有在新内核版本下编译过的程序变得混乱。随着时间的推移，为了向后兼容而带上的只浪费空间但没有作用的元素项将会使数组变得乱七八糟。相反的，这种方法只会“浪费”整数，而整数资源却无疑是非常丰富的。（另一方面，查找也会更慢，因为一个简单的数组下标还不足以满足这种方法。） 要注意的是这与有系统调用的情形相当类似：每个系统调用都与一个在系统调用表里唯一标识它位置的数字相关联。但是在这种情况里使用了一个不同的解决办法，可能由于速度在此并不重要的缘故。 procname——是用于/p