自从确认发现了最小设备驱动上的那些bug后我便稍稍地恢复了士气，所以我将尝试让Klee在更大、更复杂的驱动上工作作为下一个目标。然而，接下来的几周里涌现出新的技术难题变得难以忍受，甚至将我推向筋疲力尽的边缘。总结一下当时遇到的困难：Klee可以有效地在包含3000行（C语言）代码以内的软件中找到bug。最小的Linux驱动包含约100行代码，这是Klee完全可以驾驭的。较大的驱动包含大约1000行代码，但是和10k到20k行的Linux操作系统内其它部分代码紧密耦合。这种耦合超出了Klee的分析能力，因为让Klee“手术刀般地剥离”每个设备驱动并逐个分析它们几乎是不可能的。我尝试了诸多方法减少这种外部联系（称作依赖），但是这样做需要对每个驱动花费数日复杂的自定义人工劳动。

我找Dawson谈话并表达了当我面对的这项令人气馁的任务时是多么恼怒。在每个新的设备驱动上花费数日去使Klee能够正常在其上工作，似乎太荒谬了。不仅我在身体上筋疲力尽，而且这根本不是研究！我能在论文上写——我花费了近1000个小时的人工劳动来让Klee在设备驱动上工作，结果没有任何深刻的见解？这不是研究上的贡献，这简直听起来就是愚蠢。我也开始恐慌起来，因为距论文提交截止时间只剩5周时间，而Dawson并未提及任何关于课题组论文书写策略的事情。通常要提交一篇拿得出手的论文至少需要四周时间，尤其是一个由六个学生参与并且需要整合每个人工作的项目。

在我们谈话后几天，Dawson想出了一个方案来改进Klee从而克服我遇到的依赖问题。他发明的这项叫做欠约束执行（underconstrained execution, 简称“UC”）新技术，或许能够让Klee从10k到20k行周边外部代码中“手术刀般地剥离”Linux 设备驱动代码并逐个地分析它们。他立即着手和一个高年级博士一起将UC技术融入Klee；他们称这个改进版本为Klee-UC。尽管我已经非常疲惫甚至快要崩溃，还是欣喜地看到我的努力至少驱使Dawson创造了一个崭新的理念，这是有潜力成为有价值的研究贡献的。

Dawson和其他学生在后来的几个星期全力攻关Klee-UC。同时，他们告诉我继续尽力用以前的人工方法找Linux设备驱动bug。他们计划通过重新寻找已经被我用常规版本的Klee和人工方法找到的bug来展示Klee-UC的高效性。他们设想在文章中给出论据：Klee-UC可以在几分钟内自动找到所有的bug且不需要任何设置，而不是让一个博士（我！）乏味地花费数天设置Klee去寻找每个bug。

通过接下来几周玩命地工作，我终于能够让原版本Klee去分析937个Linux设备驱动，并发现了55个新bug（其中的32个已被相应的驱动作者通过email确认）。之后我必须安装Klee-UC雏形工具区分析那相同的937个驱动，这项工作更加棘手，因为Dawson和其他学生正在实现（编程）Klee-UC同时我还要用它去分析驱动。令人庆幸的是，Klee-UC的确可以重新发现那些bug中的大部分，所以至少我们做出一些研究贡献和结果去写到投稿论文中。

然而还有一座大山横亘在前面。当我们得到那些较好的结果时，距离论文提交截止日期只有三天时间，而且还没有人开始在论文上写一个字。在那段如此紧张的时间，书写、编辑和打磨一篇能够被顶级计算机科学会议接受的投稿论文几乎在体力上是不可能的。但是我们仍然尝试了，在最后截止日期前的72个小时，Dawson和我们5个学生（其中一个目前已经退出项目）在办公室连续打了整整两夜地铺来完成实验和书写论文。我们所有的学生都清楚地知道这篇论文是绝对不可能被接受的，但是我们服从Dawson的领导，乖乖地继续前行。

最终我们提交了一份令人窘迫的胡乱拼凑起来的文档，充斥着错别字、荒谬的句段、无注释的图表，并且还没有总结段落。这就是恐怖的一团糟。那一刻，我不知道，如果在这种可怕和无序的方式下工作，我将如何完成博士学业。果不其然，三个月之后我们的论文被拒，审稿意见上充满了负面的和严厉的评语，诸如“[程序委员会]认为这篇文章过于草率，不予录用；请勿提交未经任何检查的论文。”

《博士磨砺》&The Ph.D Grind （七）

-----------------------------------------------------------------------------------------------------------

译者电子邮件是csliweilongATgmail.com（将AT改为@），欢迎读者和我分享读后感，翻译当中若有任何不当之处，希望大家批评指正。