开机自动编译和加载drcom模块的实现原理
Henry Huang
而下个月开始，我要开始准备论文了，面临找工作的问题，所以可能就没有那么多的时间来维护这里的一切，Sorry!
我会在最近的时间，尽我的努力多写一些文档，多招些朋友进来帮忙
这篇 开机自动编译和加载 drcom 模块的实现原理
我先简单介绍一下情况，以后把详细的内容放到 developer wiki上面
http://www.drcom-client.org/wiki/
很多学校drcom 网络必须要用到 TCP/UDP 认证加头的情况，
所以必须要用到 Wheelz写的 drcom 模块
容我感叹下，drcom 模块写的太牛了，完成上述认证加头的功能。
drcom 模块是 drcom-client 立身的"招牌"，呵呵
扯远了，sorry,
现在的问题是，
随着内核的升级或者变动，原来编译好的drcom 模块将无法使用，
需要重新编译加载。
对于那些第一次使用Linux的朋友来说，这个问题比较头疼，如果把这个问题简化?
可行的办法是
开机自动检测内核版本是否变动，如果变动自动编译，编译后自动加载。
细分下来有以下几个小问题:
[1] 如何开机自动检测
[2] 如何判断内核版本是否变动
[3] 如何进行编译和加载
源码在 drcom-pum-1.0/src/kmod/scripts/ drcom drunlevel mkdrcom
[1] 必须利用 init script，启动 服务
但这里面又存在一些问题，不同的Linux发行版，init script的写法又是各自 自成一套的
如果要写通用的，必须每种 init script写法都要了解一下。
有些采用system V 风格，有些采用 BSD 风格(archlinux,slackware),还有自成体系的Gentoo
Ubuntu 甚至开始使用 upstart，不过好在 这些脚本大同小异。
解决办法:
a. 判断这是什么发行版?
常用的方法是 检查 /etc/xxx-release 文件，其中xxx是发行版的名称
if [ -f /etc/redhat-release ]; then
system=redhat
elif [ -f /etc/SuSE-release ]; then
system=suse
elif [ -f /etc/gentoo-release ]; then
system=gentoo
elif [ -f /etc/arch-release ]; then
system=archlinux
fi
b. 然后分别来考虑各自的脚本
init script -- drcom 中，其差别只是在 显示 上面，你看了源码之后会明白的。
c. 也可以使用 LSB 标准的脚本
如果有的话，脚本模板一般在
/lib/lsb/init-functions
d. 另一个难题是如何开机自动执行 init script
就是如何安装 init script
不同的发行版，系统的安装命令都不一样，archlinux似乎没有系统的安装命令，需要手动安装
---------------------------
redhat/suse : chkconfig
debian/ubuntu: update-rc.d
gentoo: rc-update
archlinux: 手动解决，将init scripts移到/etc/rc.d/然后在/etc/rc.conf DAEMON中加入drcom就可以了
---------------------------
还是前面的老办法，分别对待，对不同的发行版，采用不同的做法 --源码 drunlevel
[2] 回过头来，如何判断内核是否变动?
下面的解决办法只是一种特殊情况，你可以想想其它办法。
因为drcom模块只安装在
/lib/modules/xxxxx/extra/drcom.ko
其中， xxxxx 为内核版本号
内核一更新，新内核中的extra目录不存在 drcom.ko
所以我们就可以通过它判断出内核是否更新
我看了SUN公司的虚拟机软件 virtualbox 也是采用类似的方法。
注: virtualbox 也是需要和内核直接打交道的，有很多的内核模块要启用。
估计这也是一种"标准"的解决办法了:)
[3] 如何自动编译和加载
上面的问题解决了之后，其实90%的问题已经解决了。
下面就是 脚本 mkdrcom 的工作了
编译工作所需的源码文件，肯定是要安装在系统目录中的，如/usr/src/
编译工作不能直接在该目录下进行，因为会产生很多的临时文件，有时还会产生其它比较复杂的问题
所以需要创建/tmp/drcom 目录，并将源码转到这个目录下面进行编译
重启后，/tmp 下的文件，系统将自动清理，所以不用考虑这些临时文件如何清除
编译完成之后，就可以加载了。这里的编译，是包括安装过程的 make & sudo make install
存在的问题
开机自动判断然后自动编译和加载
会产生一个开机时间变长的问题，通常要2-3分钟，确实需要等待一会儿了。
我当时考虑，因为内核的升级也不是很频繁的，因此这种情况不多见。
virtualbox的解决方案和我们不一样，他们是通过 程序自己判断然后提示用户，需要执行
xxxxx start的命令。让用户自己去执行这些指令。
我觉得由于virtualbox所需要的内核模块很多且都很复杂，所以如果要在开机自动编译的话
等待的时间也许更长，这个影响就比较严重了。因此对于virtualbox来说，
这种提示用户来进行内核模块编译和加载的方式是符合实际情况的。
权衡了用户使用的简单性和少数几次内核升级的等待，我更看种用户使用的简单性，所以选择开机自动编译和加载模块。
各位如果有不同的意见，可以一起讨论。
这是我第一次写类似的文章，有什么地方不妥的，请各位点出，好及时改正。
谢谢!
Henry Huang