核心黑客系列之三Keith Owens

本周我们采访了 Keith Owens，一个长时间和内核打交道的有经验的黑客，他的贡献包括更新ksymoops和modutils，这两个都由他维护。他也为kbuild 2.5工作着。早些时候，他建立了最初的集成内核调试包（Integrated Kernel Debugging patch）。以及kdb和XFS。

 

Jeremy Andrews( JA):请简单介绍一下你自己

 

Keith Owens:我1952年在South Wales的Tenby出生，获得Loughborough大学的计算机学学士学位，1978年移民澳大利亚，已婚，有两个孩子，除了整天玩游戏之外，他们都不喜欢计算机，并且他们希望家里随时有一个电脑专家帮他们立刻解决所有问题:-)。

 

JA:何时并且如何开始使用Linux的

 

Keith Owens:我原来是一个大型机程序员，在IBM,ICL,CDC等等都呆过，为IBM的MVS和富士的MSP卖安全性软件。为了做文档和分发软件（on 9 inch open reel tape!）我需要一台家用机器，很“明显[1]”Unix还是未来的事，所以我得到了一台跑着较早版本的SysV的NS32032。 从那儿我迁移到SCO Xenix，但是这两种情况下在制造商（IBM和富士）看来，这都是很大的投入。Melbourne PC User Group向我介绍了Linux 0.99p112，在安装了Linux一个星期后，我扔掉了所有剩余的Xenix。 －－－[1] 在1980年时当然很“明显”了。我们花了很长时间才走到现在的地方。

 

JA:当时Linux 0.99p112和其他的相比有何不同？你一定印象深刻，因为从那时起你就一直使用Linux。是什么使你这么喜欢Linux的呢？

 

Keith Owens:自由源码，自由编译器，自给自足。Unix闭源版的制造商通常搞的我团团转。 “试试这，看看那，把它打开了吗？”:( 没有人报告过这个问题，那一定就是你的错。 最后呢……那是个Bug，在下个版将修正，但是你要付钱才行。 我宁愿花10个小时自己追踪Bug，也不想花10分钟打电话给根本不能提供支持的“客户支持”。

 

JA: 你做了哪些贡献？

 

Keith Owens: 在1.0和2.0的时候，我做了一些IP伪装（IP masquerading）和修正网络部分代码的事，没有任何代码能留下来了，因为那些代码被重写过很多遍了。 1998年，我不能忍受源代码树中的ksymoops，这是一个将内核出错代码解释成可读符号的程序。它是内核中唯一用C++编的，仅仅能处理一些体系结构，不能处理所有的消息而且也不能正确的处理模块信息。我成为ksymoops的维护者，将它用C重写，移出代码树，试图处理所有的体系结构并增添了对模块的支持。 作为对ksymoops更改的一部分，我做了一些补丁给那时的modutils 2.2来增强oops在模块中显示的能力。由于维护者太忙了，modutils后来也不更新了，所以我也自愿开始维护modutils。 我创建了一个集成内核调试（Integrated Kernel Debugging- IKD）补丁，这是通过搜集很多的内核调试补丁完成的，那时这些补丁相互之间有冲突并且缺乏文档，IKD将他们合成在一起，清除相互之间的冲突并补充如何使用这些工具调试内核的文档。其他人也对IKD做出了贡献，特别是Andrea Arcangeli和Mike Galbraith。后来我几乎没有时间维护它，所以现在Andrea和Mike在照看着它。 内核构造器（kbuild 2.4）一直有问题，特别是模块部分。问题出在输出符号，特别是模块版（modversions），甚至有一个FAQ入口。 我开始试图清理kbuild 2.4来消除模块问题，但是kbuild 2.4已经到了它生命的尽头（reached its end of life），它太复杂，bug太多，很难维护并且除了最简单的情况之外什么也做不了。所有的kbuild 2.4的维护者都认为它太难维持下去了，所以我们决定从kbuild 2.5开始完全重新设计。在开始编码之前，我们先做了期望列表和需求文档[2]－简直是怪兽（heresy）！ －－－[2]请看Source Forge Project上File List中“History”，它通过现在的CML1维护者的支持，成了新一代的配置迷你语言（Configuration Mini Language，CML2）。kbuild的另一半是makefiles，产生make命令，跟踪改变并决定什么需要重新编译。内核有特别的需求，我们希望kbuild察觉到命令的改变，补丁，配置的改变，链接顺序的改变，然后只重新编译所需的，所以kbuild2.[45]可以做大部分工作。 Eric（Eric Raymond）和我在2.5内核开发者大会上做了一个关于kbuild 2.5的演示，效果很不错。Linus已经同意在2.5内核开发周期的早期就通过CML2和kbuild 2.5进行修剪（2.5 kernel will cut over to CML2 and kbuild 2.5 early in the 2.5 kernel cycle） 我在2000年初加入SGI。他们刚失去了一个维护SGIKernel Debugger(kdb)的人而我曾提到我对内核调试很感兴趣，然后我就成了kdb维护者。Dega vu，通过改变modutils支持kdb而使kdb对模块调试有了更好的支持。 我维护着ix86和ia64的kdb，这些是SGI感兴趣的Linux系统结构，其他组织将kdb移植到他们各自的系统上。由于kdb的扩展性，其他内核组织已经开始使用kdb添加对针对他们的主要子系统的特别命令。 在SGI，我也参与XFS的工作，主要在打包和调试领域。SGI的XFS代码树包括kdb，它使得我们的生活更容易，不管是开发还是排除客户遇到的问题。现在我正在做的是将XFS+kdb移植到IA64上并检验效果。 不幸的是，linus拒绝在一个标准的内核中包含一个调试器。有些发行商已经包含了kdb（比如Redhat：译者），不管是自己包括进的还是作为XFS的一部分。

 

JA:九月份，你在lkml（linux-kernel mailing list）提到了将/proc/sys/kernel/tainted添加到modutils 2.4.9中，从那时起，就不断有lkml就这个特性优点的一些讨论。这个变化后面的目的是什么

 

Keith Owens:最初的主意来自于Alan Cox，他添加了帮助分类bug报告的MODULE_LICENSE以取代过去依赖用户提供他们到底加载什么。因为这需要modutils的支持，所以我做了insmod。那时，一些开发者希望限制向GPL only的代码输出符号（wanted to restrict exported symbols to GPL only code），这也需要修改modutils。下面是一个完整的解释 http://marc.theaimsgroup.com/?l=linux-kernel&m=100337558868172&w=2 不过，我的邮件对大众的噪音率没有任何消除的迹象，人们仍然在继续使用不正确的论述评说着这个改变。

 

JA:像我这样的一个Linux使用者在编译新的内核时，kbuild 2.5会如何影响我呢？听起来好像对于终端用户，事情变得更容易了

 

Keith Owens:配置迷你语言（CML)和真实的build可以说是完全独立的。CML的输出是main build的输入，你可以改变CML而不影响main build，反之亦然（vice versa）。 在 http://www.tuxdo.org/~esr/kbuild/ 上列出了ESR对CML的改变，特别是在ANNOUNCEMENT中。CML2对于初学者非常容易使用，同时也不会牺牲专家级人士需要的灵活性。它支持基于硬件发现的自动内核配置。消除了CML1中会让用户产生不一致性配置数据的bug。 一旦配置数据被CML创建后，kbuild 2.5从每个目录的Makefile.in段中产生出一个全局的Makefile，然后编译和链接那些绝对需要重新编译的代码。输出也很安静，每个编译或链接只占一行，可以让用户更容易的观察错误点。 所以，kbuild 2.5使得内核更容易配置和编译，只要我解决了build阶段的性能问题，速度也将更快。

 

JA:kbuild将怎样影响那些钻研内核和写模块的人呢？

 

Keith Owens:对于现有的代码，一点也不影响。ESR已经转变了CML规则，我正在转变Makefiles，添加上一条新的需要的配置选项。 Configure.help text One line in CML rules. One line in a Makefile.in 几乎和现在的一样。只有CML的格式和Makefile.in改变了，他们变得更简单并更强壮。 kbuild 2.5使得调试代码更改更容易。全局的Makefile让kbuild只重编译那些被改变所影响的代码。你可以告诉kbuild 2.5不要编译整个内核，也可以编译目录中的所有文件，递归或不递归到子目录中，你甚至为了快速检查你的改变而只编译单独的对象。

 

JA:为什么XFS不是内核主代码树的一部分，对－ac的内核分支呢

 

Keith Owens:XFS改变了内核代码来支持直接I/O（Direct I/O)与延迟分配（delayed allocation）。延迟分配使得文件的创建，读写和删除的速度大幅提高。如果有足够的内存，延迟分配将永远不读写磁盘，节省了很多I/O时间。 不幸的是，延迟分配改变了VM子系统。由于VM不断的改变，这个设想还不能被接受。我们只有等这2.5了，也许那时再移植回到2.4上来。 对于-ac分支就更糟了，那是一个完全不同的VM。XFS并不支持-ac代码树，虽然KDB可以。不能不提到的是，RH 7[1,2]内核有很大一块来自-ac代码树，但是SGI针对RH 7内核做了一个补丁。我们并不是每天都跟踪-ac代码树。我为了kdb和kbuild 2.5会跟踪-ac代码树的改变。 一些发行商已经将2.4内核同XFS一起发行，Mandrake 8.1就是。SGI针对RH现在的发行版提供了一个XFS的安装器。AFAIK Debian也有XFS包。

 

JA:我目前基于两个主要的原因使用ext3：与ext2兼容而且-ac分支包含它。XFS与它比较如何，从ext2或者ext3切换到XFS有多难？

 

Keith Owens:为了切换到XFS，你要备份数据，重新格式化分区并重建所有的数据。这些任何文件系统都需要的，但是ext2和ext3却是例外。

 

JA: 如果再切换回来有多困难

 

Keith Owens:因为你不得不备份并恢复所有的数据，所以你不会每隔几天就切换一下。在你使用了XFS额外的功能，比如ACLs〔3〕和DMAPI〔4〕后在切换回来是很痛苦的。SGI正在和其他组织一起合作开发一套标准的ACL接口和工具来使得维护多个文件系统并在他们之间移动数据变得更容易 －－－〔3〕The interface with the kernel (system calls) for Access Control Lists (ACLs) and Extended Attributes (EAs) is different in XFS/Linux compared with IRIX －－－〔4〕Files required by system software using the Data Management API (DMAPI)：译者from google

 

JA:为什么Linus拒绝包含kdb?

 

Keith Owens: http://www.lib.uaa.alaska.edu/linux-kernel/archive/2000-Week-36/0575.html

 

JA:为什么kdb应该被包含在内核中

 

keithOwens:

http://marc.theaimsgroup.com/?l=linux-kernel&m=96865229622167&w=2

 

JA:我经常使用gdb调试C代码，kdb与gdb有什么不同

 

Keith Owens:kdb是设计进行更低层次的内核级调试的。当一个内核陷入kdb，所有的中断被禁止，这意味着无法使用磁盘和网络I/O。当你查找内核问题并保证数据不变化时，禁止所有的中断是唯一的办法。该方法的缺点就是你不能通过读磁盘来得到gdb需要的字符类信息。kdb可以通过一个串行控制台或者一个PC控制台运行。推荐的调试环境是在一个串行控制台上使用两台机器，一个用来调试问题，另一个用来察看源代码。我们察看源代码的那台机器运行着gdb，它和另一台机器上的kdb对话，但是gdb串行链接协议（gdb serial link protocol）不够灵活。gdb5中含有更好的脚本，看上去是很有希望的，我希望能看到一个gdb/kdb的接口（在某天）

 

JA:做开发时，你使用那些工具

 

Keith Owens:vi,gcc,gdb,PRCS（就像CVS，译者）,kdb，我的笔记本（当然使用的是XFS）安装了PRCS当做主要的源代码存储库，其他地方的机器用做备份。我要感谢Andrew Tridgell写了rsync，它使得备份工作如此的容易。也要感谢Josh MacDonald写了PRCS，我的2.4内核树包含10个分支的超过700个补丁。我需要一些比CVS更好的工具跟踪这些变化。 我家里有一些x86的机器，单CPU和双CPU的都有。除了给小孩玩游戏的机器外都装了Linux。在SGI我可以接触到各种机器，包括MIPS和IA64。SGI有很多用于各种环境编译和测试的机器，那是个很棒的工作环境。

 

JA: 你使用过那些操作系统，于Linux比较，你喜欢或不喜欢他们那些方面

 

Keith Owens:从大型机分类的话有：ICL(Maximop, George 2, George 3, VME)， IMB(VS1, MVS, OS/390)，Fujitsu(MSP)。我仍在使用IBM，最近我为IBM的Unix System Service做了一个表演系统（performance system for IBM's Unix System Service）（很奇怪，是MVS下的Unix）。当我能访问合适的大机时，我为MVS维护infozip。 ICL的George 3就更早了。它是基于目录的文件系统，所有的东西都集成到文件系统中。一个目录项包含目录名，谁可以访问它以及备份的拷贝在那等等。你甚至可以将比较老的文件搬移到磁带机中，只留下目录项。当你访问文件的时候，它将自动装载磁带机并恢复它。你也可以得到OS的源代码，那可是发生在1975年！ Linux文件系统只有通过ACL（访问控制列表，Access Control Lists）才能达到这样的阶段，只有一些系统可以使用ACL，其他的系统只能通过自动存档和还原了。据我所知（AFAIK: As Far As I Know ），XFS是仅有的两者都具备，也就是ACL和DMAPI。 MVS使人头大，每件事都是特别的情形。当使用单用户启动时，它似乎有360种血统，是不值得谈论的操作系统。如果你想得到某些系统的数据，你不得不自己使用系统控制块得到它。当360被370,390等等代替，IBM推出了VS/1，然后是MVS，IBM一直保持着“自己找吧（find it yourself）”的设计原则。 最后IBM开始隐藏系统数据并提供标准的获得数据的接口。不过很多接口是以OCO（Object Code Only）发表的，并且只有很少的文档，所以只有IBM自己才会用，没有第三方和客户使用。我非常确信OCO是IBM失掉很大一部分服务器市场的比较主要的原因，客户都去选择他们能控制的系统去了。

 

JA:ICL和他们的George操作系统发生了什么事

 

Keith Owens:IBM有更好的销售人员和一群守旧的人。ICL将所有的东西都打到一个软件包里，买了OS，你就有了备份，恢复，在线访问（别忘了那还是处理机的年代），数据库。IBM将各部分分开，使得刚开始买的价格看起来很便宜。 我们能卖给你有双倍内存但及格仅为ICL一半的IBM机器！哦，你想要备份和恢复？没问题，额外收费；在线访问？收费；数据库？收费；编译器？收费。 一个公司从ICL 1900上的George 3系统转到IBM 370的VS/1，在ICL上我自己做数据库管理员和系统程序员，如果我一个星期多花两天的时间在OS上的话，那么一定是出了很严重的问题。在IBM 370上，我们用了4个系统程序员和2个数据库管理员，最后结束的时候还累的精疲力尽。 George操作系统是为1900系列做的，后来ICL推出了2900系列和一个新的称为VME/B的OS。2900有一个很可爱的硬件设计，在用户空间和系统空间实现多环保护（就像X86 CPU的4个Ring Level的设计吧，环越低，特权越高。译者）。Ring 0是dump和debug代码，所以即使OS在高环上死机了，你仍然可以找出到底那里错了。数组（Arrays）由包含长度字段的硬件描述符处理，如果你试图使缓冲区移出，那么硬件会阻止你。 不过ICL最后还是失掉了同守旧的IBM的这场战争。最近一次我发现，ICL成了一个IT服务公司。

 

JA:你对2.4内核系列目前的状态作何感想，你认为它稳定吗

 

Keith Owens:内核的核心是稳定的，除了最近（2.4.10)的VM改变外。一些单独的驱动没有被人维护了，但是我们却几乎可以认为一个分布式的维护系统已经形成了。

 

JA:为什么不运行OpenBSD作为你的防火墙

 

Keith Owens:因为我没有时间学习其他别的OS。我对Linux的安全性感到很满意，我只有不得不升级的时候才会升级我的系统

 

JA:你对将要到来的2.5内核最期望的是什么，你认为它何时开始呢

 

Keith Owens:kbuild 2.5！越快越好啊。刚开始的时候它可能会产生一大堆问题，特别是在没有经过完全测试的体系结构上。一旦问题解决了，kbuild 2.5将解决内核编译的很多问题。 kbuild 2.5也将使得我们现在不能做的事称为可能。我们有两种向内核传递参数的方法，一个是启动时的命令行（针对内建的部分）或者是modules.conf（针对模块）。这两种方法并不兼容，每个开发者需要写两段代码，到底执行那段代码将取决于该代码如何编译。kbuild 2.5提供了缺失项（missing piece）并将提供一个指定参数的一致性的方法。 一旦kbuild 2.5进入内核代码树，我将开始modutils 2.5。这将摆脱许多有关兼容性的问题，modutils目前向前支持到2.0内核，不过当我想改变任何东西的时候会出问题。这是modutils的bugs，我不能在不影响当前用户的前提下修改它，因为那样的话将破坏向后兼容性（backwards compatibilty，不能兼容前面的版本。英文中的向前和向后与中文表达有出入，向前指ahead，future，向后指back，yesterday once more。中文太强大了，正反都能说。不知如何翻译好呢？译者）。我并不想被指责。Modutils 2.5将被重新设计并将打破向后兼容性，所以它只能被用在内核2.5上。很明显的，如果你启动一个2.4的内核，那么你需要回退到modutils 2.4。 另外，2.5的kbuild不需要到处加上MOD_INC_USE_COUNT来消除模块卸载竞争（module unload race）。Rusty Russell和我已经讨论了这个问题，但是对我来说，这要等到kbuild 2.5和modutils 2.5以后的版本了。我希望一些体系结构更好的集成到linus（注：是linus，不是linux。译者）的代码树中来。但是没有一个合适的研发版内核让我能理解为什么每个arch在代码树中是独立出来的。我们需要在推出稳定版之前在一个研发版内核上测试集成性。 我们什么时候才有一个研发版内核？我不知道。

 

JA:打破先后兼容性而重写moduitls有很大的阻力吗

 

Keith Owens:因为对于比较老的版本只要回退到modutils 2.4就行了，所以没有人抱怨向后兼容性吧。我相信对于新的文件格式回有抱怨，但是这就是开发版的作用啊

 

JA:你遇到过Linus，Alan或者其他内核开发者吗

 

Keith Owens:一年前在新加坡我遇到过Linus，在澳大利亚Linux会议上遇到过不同的内核开发者。在San Jose举行的2.5内核开发者大会是个很好的机会，见到了大部分内核开发者，并终于把名字和样子对上号了（put faces to names） http://marc.merlins.org/linux/linux.conf.au_2001 http://lwn.net/2001/features/KernelSummit/

 

JA:你对Linus的印象如何

 

Keith Owens:尽管他声称自己很容默许别人（a conniving bastard）。我发现正好相反，他不会高兴的被愚弄，而且他会抓住你希望别人不会注意的弱点猛攻，但是给他一个很充分的技术上的反击，他会听的。

 

JA:你能谈谈对核心2.5内核开发者大会的印象吗

 

Keith Owens：虽然面对面谈话很有帮助，但是最大的好处就是大家聚在一个白板周围然后争论那些技术问题。Email是不错的，但是不久你会发现需要一个白板才能讲的更清楚。我发现本地会议也基于同样的理由而很有帮助，如果一些内核开发者可以聚在一起，你会发现很多问题将非常快的解决掉。

 

JA:你“非Linux”时间做什么

 

Keith Owens:滑雪，10瓶保铃，潜水和科幻小说

 

JA:对于渴望称为内核黑客的人，你有什么建议和提示

 

Keith Owens:如果你有兴趣，发掘它。你不必想着发现或解决大问题，挑一些小的东西然后修正它。我从ksymoops开始，从那走到这里。如果你不能贡献代码或文档，不要紧，有人想为我重写Modules HOWTO吗

 

JA:最新的Modules HOWTO在那里

 

Keith Owens:网上的那篇相当旧了。前一个维护者发给我原始文件和更新文件，但是他和我都太忙了。我希望有人能清理这些文件并修正它。

 

JA:最后，你还有什么要补充的吗

 

Keith Owens: 反抗垃圾邮件（spam），软件专利权（software patents ）和DMCA（The Digital Millennium Copyright Act (DMCA).The DMCA is being used to silence researchers ）/SSSCA（Security Systems Standards and Certification Act）。Alan和我一样，在DMCA的有效期内，我将不会到USA参加任何会议。

 

JA:非常感谢你回答了我所有的问题，今天我受益良多。