文章存档
分类：
2007-05-09 21:43:17
现在我要把一个类似如文件系统的东东从kernel 2.4升级到2.6。有点象nfs，但有不是。花了好几天的时间把代码格式和公共的部分(2.4, 2.6)分开了一点。现在在2.4, 2.6下可以编译过去了，测试就开始了。现在cd, ls, df功能已经可以使用了。测试cp时老是死机，很是麻烦。
内核开发测试真是麻烦，kdb现在还没怎么会用，两台机器测试吧条件又不允许，死机已经很习惯了，关键是你不知道在什么地方会导致死机。哎，很是麻烦，不可以单步执行哦！！！
在以前开发东西时总喜欢先把main写好，再在每个功能中慢慢的添加到main中运行来测试，认为很不错。写出来的东西没有经过测试的，很是危险的，千万不要把所有的都做好了再来测试，那样会累死人的，而且做出来的东西bug一定很难找，哪怕每个小功能你也要想办法构件测试环境来测试它的，要不谁敢保证它就是对的哦。结果奇怪是，后来看有关测试方面的书说这叫迭代测试，我的天啊，原来那些东西早有了，不知道哦，哪怕学了也忘了，用的上的就是好的。
今天象我这样的一下子写那么多程序该怎么测试呢？找了一天，认为这样比较好。该方法对内核开发可以使用，对其它的也一样可以哦，不过好象对其他用gdb就可以代替了，没有必要了。
我自己给它起的小名为排除法。如cp命令会调用下面这个结构中的myfs_file_read函数，
struct file_operations myfs_file_ops=
{
.owner = this_module,
.llseek = default_llseek,
.read = myfs_file_read,
};
那么你就在该函数
static ssize_t myfs_file_read(struct file *file, char *buf, size_t count, loff_t *off)
中适当的位置添加return (-ebadf);就可以了，如果你的测试可以执行到return处就说明在该return前面的代码是没有问题了，这样你对每个函数一步一步的添加相应的return就可以了。注意哦，内核开发中你在死机的情况下添加了printk你也是没办法看到输出的。
慢慢一步的排除正确的代码，找到出错的位置。
测试中的应用小节：
1>. 迭代的去开发你的每一个功能。
2>. gdb没办法时可以考虑添加合适的return来排除正确的代码，找到错误的位置。
内核开发测试真是麻烦，kdb现在还没怎么会用，两台机器测试吧条件又不允许，死机已经很习惯了，关键是你不知道在什么地方会导致死机。哎，很是麻烦，不可以单步执行哦！！！
在以前开发东西时总喜欢先把main写好，再在每个功能中慢慢的添加到main中运行来测试，认为很不错。写出来的东西没有经过测试的，很是危险的，千万不要把所有的都做好了再来测试，那样会累死人的，而且做出来的东西bug一定很难找，哪怕每个小功能你也要想办法构件测试环境来测试它的，要不谁敢保证它就是对的哦。结果奇怪是，后来看有关测试方面的书说这叫迭代测试，我的天啊，原来那些东西早有了，不知道哦，哪怕学了也忘了，用的上的就是好的。
今天象我这样的一下子写那么多程序该怎么测试呢？找了一天，认为这样比较好。该方法对内核开发可以使用，对其它的也一样可以哦，不过好象对其他用gdb就可以代替了，没有必要了。
我自己给它起的小名为排除法。如cp命令会调用下面这个结构中的myfs_file_read函数，
struct file_operations myfs_file_ops=
{
.owner = this_module,
.llseek = default_llseek,
.read = myfs_file_read,
};
那么你就在该函数
static ssize_t myfs_file_read(struct file *file, char *buf, size_t count, loff_t *off)
中适当的位置添加return (-ebadf);就可以了，如果你的测试可以执行到return处就说明在该return前面的代码是没有问题了，这样你对每个函数一步一步的添加相应的return就可以了。注意哦，内核开发中你在死机的情况下添加了printk你也是没办法看到输出的。
慢慢一步的排除正确的代码，找到出错的位置。
测试中的应用小节：
1>. 迭代的去开发你的每一个功能。
2>. gdb没办法时可以考虑添加合适的return来排除正确的代码，找到错误的位置。
给主人留下些什么吧！~~