Kernel Defects Before and After Release

I’ve tried to analyze the defect data of Linux Kernel to find out the answers of the following questions.

1. How much effort the release candidate period should give?

2. Does the quality of stable kernel(stable kernel without update) becomes better or worse?

To figure out the questions, I gathered the following datum.

1. Pre-RC Changed Lines: The lines of source code changed between 2.6.(n-1) and 2.6.n-rc1. These source codes are confluxed during merge window period of each version of kernel. They are mostly implemented for new features of a new version of kernel, which needs a long period of testing and fixing after merge window closes.

2. Defects found during RC: Because mainline almost only accepts bug fix patches in RC period and we encourage one patch per bug, the patch set quantity of RC approximately represents quantity of defects found in RC period, which we call internal(inside development community) testing period. This data comes from git-log between 2.6.n-rc1 and 2.6.n.

3. Defects found after release: After stable kernel release, users and developers themselves will find some bugs and fix them. To eliminate the unfair caused by different release time, I only collect the stable kernel defects which was fixed before next 2.6.x stable release. For example, if 2.6.n was released on 2009.A.B and 2.6.(n+1) was released on 2009.C.D, the “Defects found after release” means the fixes for 2.6.n stable kernel before 2009.C.D. Actually, I dig the data from GregKH’s stable git trees.

By putting the RC defect ratio(”Defects found during RC”/”Pre-RC Changed Lines”[kstep]) to X-axis and Stable defect ratio(”Defects found after release”/”Pre-RC Changed Lines”[kstep]) to Y-axis, I got some interesting graphics here.

Wait… What do you expect to see? More RC fix bring higher quality of stable kernel?

1. Picture-1 maybe disappoints you. We see here: the more bugs got killed during RC the more complaint from stable users or developers.  Why? I don’t remember who said this, but I remember these words “Finding MORE defects means as MORE defects unrevealed”. RC defect rate doesn’t mean that the more bugs fixed the higher quality of release. Instead it tells us whether new features have a trustful quality before being sent into merge window. Developers should well test their patches of new feature as well as the patches for RC. So here comes another question: we can’t keep doing RC forever, thus when should we stop RC and goto release.

Linux Kernel defects before and after release

2. Picture-2 shows that RC fixing increased nearly as linear trend according to different Pre-RC code quantity. But trend is trend, some kernel releases didn’t have enough defects be found during RC and some had above-average RC defects ratio. Let’s go back to Picture-1, we can see densest RC defect ratio region is about 2.5-3.0 defect/kstep, and the average RC defect ratio is about 2.87 defect/kstep, which is marked by the red ordinate. Below the average RC defect ratio, four of ten releases have above-average stable defect ratio. If we set a rule to not allow ending RC when the RC defect ratio is still below average, we can make “the four” releases more stable.

Now we have seen two pictures of whole kernel defect ratio, but how about subsystems?

RC Fix according to merge window quantity

X-axis: Pre-RC Changed Lines, Y-axis: Defects found during RC

3. Not only whole kernel should have a RC defect ratio gate, each subsystem also should not allow too low RC defect ratio. Let’s see some.

Network subsystem is almost like whole kernel, stable defect ratio increases as RC defect ratio increasing. “core kernel”, “fs”, “arch” and “block” are almost as same, which I don’t paste here to save my host’s space ;)

network subsys

network subsys, X-axis: RC defect ratio, Y-axis: Stable defect ratio

Sound subsystem is some kind of strange.  When RC defect ratio exceeds 3.0 defect/kstep, stable defect ratio begins to descend. In my superficial opinion: very strong RC effort(seven times of average) causes higher stable quality. At this point, very high RC defect ratio no longer means “Finding MORE defects means as MORE defects unrevealed”, but means “Highly quality control reduces unrevealed defects”.

sound subsys

sound subsys, X-axis: RC defect ratio, Y-axis: Stable defect ratio

Memory Management looks like an ideal descending trend, if we ignore 2.6.16, 2.6.20 and 2.6.21. In mm, RC defect ratio is very higher than any other subsystems, because mm is essential part of core kernel and rarely changes.  I don’t recall what happened on the three releases, maybe something like virtualization supporting can cause such a defect boom.

mm subsys

mm subsys, X-axis: RC defect ratio, Y-axis: Stable defect ratio

4. This is the last graph which answers my question about “Does the quality of stable kernel becomes better or worse?”. From 2.6.14 to 2.6.30, stable kernel has an average defect ratio about 0.32 defect/kstep. Since 2.6.23, kernel tends to keep a lower stable defect ratio, although 2.6.27 and 2.6.28 departed from the trend. I’d like to say maybe we are releasing kernels of better quality.

Stabe Defect Ratio Trend

Stabe Defect Ratio Trend

As Linus said at Linuxconf this week :”Linux is bloated“,  it doesn’t only means that kernel got bigger and bigger, but also means that kernel grows up faster and faster. So when to release a new kernel not only depends on time and RC rounds, but also depends on defect ratio and new feature’s influence scope.

小偷和法官对互联网说”不”

丰富而强大的互联网应用使我们的生活变得越来越便利和精彩,但是也给某些职业带来了风险。暂且不管国内闹的沸沸扬扬的“戒网瘾”大潮,放眼国际环境我们也能找到一些对互联网说“不”的人。

Facebook 和 Google Search应该是现在互联网上的两大当红应用,但是近日发生的两件事情让我们不得不小心地去使用它们。

事件一:19岁的Jonathan Parker受Facebook毒害严重,日常生活几乎不能没有Facebook,甚至在他入室盗窃的那小会都惦记着自己在Facebook中的社会关系,并且在网瘾的驱使下使用被盗人的电脑登入了Facebook,检查了自己的留言箱。显然如此不专业的行为影响了小偷的工作专注度,在离开现场时,他居然没有退出登入。当然Jonathan在数小时内就被捉拿归案了。

教育意义:此事件告诉我们,工作就是工作,如果上网影响了工作,那么就会丢掉工作。另外在他人电脑上登入帐号后,一定要记得退出登入。

事件二:美国法官命令陪审团在案件审理期间不允许使用个人电子设备访问外部信息。众所周知,美国的陪审团制度要求,为了公平理性地审理案件,陪审员不能在审理期间阅读报纸或电视新闻中有关本案的内容,以免被媒体观点左右。但随着互联网技术的发展,人们现在可以非常容易地通过iPhone访问Google来搜索信息。因此最近有法官准备让陪审团在开庭之前签署一份协议同意不使用移动设备查看任何跟案件有关的外部信息。

教育意义:信息透明和对等不是普适的,在最民主的国家,维护民主的法律却需要信息的封闭来保证得以执行。

精确估算

你有碰到过一个完全新的项目没有历史数据可以借鉴而无法正确估算吗?

你有碰到过由于估算的失误导致开发团队加班加点还无法满足客户的抱怨吗?

本文将向你介绍基于实战的具体估算方法来避免以上的悲剧发生。 

任何项目启动初期都会进行项目估算,当然软件项目也不例外。首先不提那些不做项目估算的项目,目前很多项目就算进行了所谓的项目估算,实际的执行也往往和估算差之千里。笔者认为,既然是估算当然允许误差,但是这并不代表所有的估算都会有很大的误差。我们有很好的方法可以帮助软件项目经理在估算时做到尽量的接近目标。 

这里要先提一下项目估算中的2423法则,通过这个法则我们发现差的估算会让项目团队陷入吃力不讨好的境地。如下图中所示,项目初期对于真正的困难会自然地察觉不到(注意:这是很正常,也难以避免的),因此把4个单位的项目规模估算为2个单位,接下来在初期设计完成后,开发团队对于项目有了更深入的了解后,发现原来需要做的工作有4个单位。这时再跟用户商量时,用户自然产生不满(试想:你家装修到工程的一半时,装修公司跟你说价格要翻一倍,这如何能接收)。为了尽量满足用户,开发团队就不得不在不可能的情况下加班加点,而这样也顶多完成3个单位的工作,结果为了支付加班费,公司多花了很多钱或者亏本,而最后的成绩也不被用户认可。

2423法则

2423法则

 

既然在项目初期很难避免要件的忽视,那么我们有什么办法可以在估算中尽量做到准确呢?答案是根据项目类型使用系数调整。试想如果估算初期就把2个单位的工作×2得到4个单位的工作规模的话,一切问题不就迎刃而解了吗。当然,我们不能拍拍脑袋,随便往任意一个估算上都乘以2。那么到底需要考虑哪些影响系数的因素,每种影响又有多大的系数呢?笔者将根据经验给出以下调整点。

  • 开发对象的特质

a) 上层应用软件/底层基础软件:开发对象是接近用户的上层应用呢,还是底层操作系统内核?【0.6(上层) ~ 2.0(底层)】

b) 逻辑/GUI:开发对象是以逻辑为主体呢,还是界面为主体?【0.6 (GUI) ~ 2.0(逻辑)】

c) 动态/静态:开发对象是动态处理(动态获得数据)居多,还是静态处理(数据定义,HTML描述)居多。【0.3(静态) ~ 1.0(动态)】

d) 新开发率:开发对象有多少是完全新的代码,有哪些是既有的修改。比如开源项目的参与开发,由于需要在原有代码上修改,虽然修改量不大,但是付出的劳动跟数倍于它的新开发差不多。【0.5(100%新) ~ 2.5(新开发率低)】

e) 需求的确定性:用户对于开发对象的需求是否确定。【0.7(确定度高) ~ 2(确定度低)】

  • 技术/工具

a) 开发技术的成熟度:对于开发对象所需的技术成熟吗?比如有现成的框架可用。【0.6(成熟) ~ 2.0(不成熟)】

b) 开发语言/工具:开发语言是高级语言还是低级语言?基准语言设定为C语言,其他语言跟它的比较可以通过组织内的历史代码得出。【0.6(高级语言) ~ 2.0(低级语言)】

以上因素累积乘以通过一般方法估算出的结果(代码量,文档页数,测试case数),一般都会得出一个1.5~2.0倍的新估算结果。这个结果和代码量,文档页数等不同,它才是真正的规模,通过它来跟客户讨论要在合同上签多少钱的单。

看到这,整天抱怨自己的项目是一个火星项目,在组织内没有可供参考的生产性数据的项目经理们也可以停止抱怨了。不用自己去定制生产性,只需根据以上规则调整开发规模即可。

微软挑开视觉搜索战幕

微软的搜索引擎Bing(必应)近日提供了新的搜索模式-视觉搜索,其搜索模式如下:

1. 输入关键字,例如”FBI’s most wanted”.

2. 搜索结果中会出现一个相册,相片里会提供跟关键字关联的图片,例如一组被FBI通缉的疑犯照片.

3. 点击你需要查看的图片.例如点击拉登的照片.

4. 显示所有跟拉登相关的网页搜索结果.

这种新的搜索模式,可以弥补现在完全基于文字的搜索的不足.

例如你在家里打扫卫生时,发现一只完全不认识的蜘蛛,你不知道它有没有毒,也不知道它的学名是什么.这时你就可以上Bing,搜索”spider breeds”,然后从相册中挑选一个长得跟你家蜘蛛一样的家伙,点击搜索你就可以知道它叫什么蛛以及是否有毒.这样的便利是现在的文字搜索所不能提供的.

笔者在数年前曾经有过这种类似的想法,当时希望:如果把一个不认识的物体用手机拍照后上传计算机,然后把图片作为搜索的关键字传给google就能得到相关信息.看来微软已经先行一步,通过静态的相册达到视觉搜索的目的,下一步应该就是笔者期望的动态图片关键字搜索了吧.

PS:

1. 目前的Bing视觉搜索只有美国版提供,地区版会自动跳转到各地域的Bing服务器,只要主动选择美国服务器后,再次选择视觉搜索即可.

2. 微软的Bing视觉搜索服务需要客户端软件SilverLight支持,使用Bing时会提示用户下载和安装此软件.

OK, 去试试吧,看看你家楼下的小狗是什么品种 :)

南京十年

  今天是我来到南京十周年的日子。

  十年前,背着行囊来到这座陌生的城市,在略显偏僻的校园开始了我的大学生活。

  十年间,学到了很多的知识,懂得了很多的道理,改变了很多的想法,认识了很多的人,得到了很多的帮助,领悟了很多的人生。

  十年后的今天,生活在这个熟悉的城市,不再为陌生的环境所困扰,体会着城市角落中的点点滴滴。

  我曾经评价南京是一个很土的城市,因为这个古老的都城沉淀着很多的历史,凝重而又充满韵味。我是土人,土人生活在这个土城市中,很踏实。

  周末同学结婚,顺路回到学校看了看,新生刚刚报道,而且今年一改以往的传统,军训由大二改到了大一, 操场上充满了生机和活力。

  十年,这个城市、这个城市中的人,很多发生了变化、很多还是没有变。贴几张学校的照片,体会一下这变与不变。

  

新建筑:“见山园”暨中国艺术研究院中国雕塑院创作基地
新建筑:“见山园”暨中国艺术研究院中国雕塑院创作基地
  
建设中:逸夫楼
建设中:逸夫楼
  
建设中:图书馆与实验中心楼群
建设中:图书馆与实验中心楼群
  
老校门
老校门
  
南楼(尚贤楼)
南楼(尚贤楼)

微软向Linux提交代码能走多远

微软虚拟机代码可能被移出Linux!

Linux驱动维护者GregKH在为Linux-2.6.32的merge window做准备时整理了现有的staging目录。对于微软提供的虚拟机hv驱动代码发表了一下的观点:

hv (Microsoft Hyper-V) drivers. Over 200 patches make up the massive cleanup effort needed to just get this code into a semi-sane kernel coding style (someone owes me a bit bottle of rum for that work!) Unfortunately the Microsoft developers seem to have disappeared, and no one is answering my emails. If they do not show back up to claim this driver soon, it will be removed in the 2.6.33 release. So sad…

目前的hv还没有进入mainline,但是在Greg的patch队列中可以看到hv的代码确实来自于微软。微软在2009年七八月份时把她的Hyper-V技术相关的驱动代码以GPLv2的许可权方式贡献给了Linux内核社区。其主要目的是希望Linux可以运行在Windows2008及其Hyper-V虚拟机之上。

对于如此巨大的贡献,Greg自然非常乐意接受,可是在Greg提出一系列TODO后,微软的开发人员反应非常缓慢,导致Greg发了以上的观点。虽然hv还是有可能在2.6.32的merge window期间加入mainline,但是如果微软的工程师继续不理会Greg的要求的话,hv也有可能在2.6.33的开发期间被移出。

好在微软又做出了反应,这次的微软Linux合作得以有继续的可能,我们也将拭目以待这次重大的合作是否能给微软和Linux带来双赢。

Linux内核社区投稿

2年前指导公司内部人员如何提交Linux内核Patch时整理的wiki资料。在这里共享,主要介绍Patch作成时,以及社区对应时的注意点。

1.  patch制作

1.1 bug修正

bug修正时请注意以下几点:

  • 是否没有多余的注释。
  • 注释是否符合kernel doc format。
  • 是否include了多余的头文件。
  • 函数原型是否用了#ifdef。
  • 一个画面内不能显示#ifdef和#endif时,是否添加了/* CONFIG_NAME */ 这 样的注释。
  • 应该使用EXPORT_SYMBOL_GPL()的地方是否使用了EXPORT_SYMBOL()。
  • 使用scripts/checkpatch.pl检查一下。
  • 修正后是否再次编译并测试。
  • 修正后编译是否有warning。

1.2 生成patch

生成patch时请注意以下几点:

  • patch是否太大超过邮件服务器接收单封邮件的上限。
  • 一个patch只修正一个问题。类似patch分为多个作成系列,用[n/m]的形式发送。
  • 是否明确描述了patch的目的。patch被采用时,这些说明会直接放入Changelog。尤其是反映了社区的意见后再次投稿时容易忘记,请注意。
  • 是否对正确的版本制作的patch。
  • patch制作时的当前路径是否是新旧两个版本所在路径的父目录。
  • patch制作后是否应用并再次测试过。
  • 内核patch最好使用git生成。
  • diff的参数尽量使用 -Nurp

2.  patch推进

如果推进时已经有人正在社区中推进相关内容的话,请停止patch的提交,而只参与讨论。

2.1 问题再现方式

  • 请假设将要面对的社区的维护人员不能理解你在source层的解释,他只能理解更浅显的说明方式。
  • 再现的程序尽量是一组command的组合。
  • 如果有多种情况可以再现同一个bug的话,那请挑选最自然的方式。假设有个bug导致任何l打头的命令都不能使用。再现方法有多种,以下三种,哪个更好?
a.#lamnotacmd
b.#lshal
c.#ls

首先abc确实都能再现bug,但是a使用了一个不存在的命令,b使用了一个存在的命令,但是并不常用,显然c在实际应用中更加频繁和自然。c作为再现方式的话更容易被社区的维护人员理解和接受。

  • 如果这个bug有时会引起kernel panic,有时不会,那请不要忘了告诉社区kernel panic的事,这样可以引起重视。

2.2 邮件格式

  • 邮件的标题是否合适。
    • 投稿多个不同的patch时,必须分别采用不同的邮件标题。(标题为 patch名。例:”Subject:[PATCH] mm: fix a bug in container driver” → fix-a-bug-in-container-driver.patch)
    • 投稿一个系列的patch(为了一个目的制作的patch,因为太大的原因 而进行了分割)时,标题上必须添加编号。例:”Subject:[PATCH 1/4]…”
  • 邮件采用纯文本格式,并且每行字长小于72字节,不要使用英语以外的文字。
  • 邮件的签名不要使用公司统一的复杂签名。
  • 邮件作成后,直接另存为*.patch,用这个patch再试验一次是否能打上。因为社区维护人员大都直接把mail另存后作为patch使用。
  • 是否添加了必要的Signed-off-by, Reviewed-by, Tested-by。
  • Thunder Bird 发送patch时的配置(防止tab自动转换为空格):
    • 1 工具->邮件/新闻账户设置 选择“通讯录”去掉“以HTML格式编写消息”的选框
    • 2 在C:\Documents and Settings\YourName\Application Data\Thunderbird\Profiles\xxxxxx.default目录下生成user.js文件,文件内容如下
      • user_pref(”mailnews.wraplength”, 0);
      • user_pref(”mailnews.send_plaintext_flowed”, false);
    • 3 重启ThunderBird就可以了

2.3 和社区讨论

向社区投稿时请注意以下几点:

  • 投稿地址是否正确。(查看MAINTAINERS中相关人员后To or CC)
  • 讨论时回复邮件请不要置顶回复,应该在对方的邮件的正文中插入回复。

2.4 patch采用后的对应

patch经过社区review后,认为没有问题,就会被采用。 但是采用后,发生问题的可能性仍然存在。 比如,某个服务器制造商在自己的服务器上运用patch后,可能会由于硬件平台的差异,引起新的障害,这个时候大家就会讨论是否要把patch退回。 因此,出现这种问题后,需要迅速对应,否则很有可能被采用的patch又被退回。

Linux-2.6.31 was released

Linus released Linux-2.6.31 on 2009-09-09 USA time.

What I am focusing on is the development status of kernel. And by the KPS tool,  I found some interesting points below.

1. The new joining engineers increased since 2.6.29 after a long time continuous decline since 2.6.25, when one and half years ago. 

Linux Kernel New Joiner

Linux Kernel New Joiner

2. Although more enginners joined kernel development, involved companies declined 2.6.29.

3. To look at Report, Review and Test, we can find out that more and more people are contributing to Linux by doing QA job. 

Linux Kernel QA

Linux Kernel QA

4. Not like USA or Europe, Chinese engineers joined kernel development these years, their contribution become more and more recently.
Chinese Patch contribution

Chinese Patch contribution

云计算的安全问题

前文所述,云计算并不能让企业非常放心地去使用它,原因是目前的云计算还有可能存在很多风险。本文仍将通过类比电力系统来说明云计算的各环节中存在的诸问题以及可能的解决方案。

 

前文已经讲过,云计算具备最基本的三个环节:分布计算节点,计算能力集群和再分配的云,计算能力的用户节点。这三个环节中的任意一个出现安全问题,或者任意两个的连接处出现安全问题,都有可能带来整个云的崩溃。由此可见,对于云计算的安全管理问题要远远比企业内部服务器或者是PC的安全管理来的更复杂。

 

首先,对于分布计算节点这个环节,安全管理要相对比较简单,这个环节的安全监管和目前企业内部服务器以及PC的传统意义上的安全监管类似,需要对每个分布计算节点进行普通的安全管理。在这个环节要至少保证分布计算节点被入侵的成功率尽量低。就像发电厂内的工作机组一样,单单一个发电机组不工作,对于社会的供电是不会有影响的。但是每个机组至少要有相应的防火或点检措施,保证大多数发电机都能正常工作。不过值得注意的是,后云计算时代的“终端即计算能力”模式中,分布计算节点可能已经不单单是数据中心里的计算节点,而可能就是一台在使用云的用户终端。那么这样的分布计算节点在我们的安全框架下是很难照顾到的。我们不能要求使用云的用户都在其终端上安装指定的安全模块。所以下一个环节的安全是非常重要的,它负责替分布计算节点做掩护。

 

那么,计算能力集群和再分配的云环节,也就是云计算的核心环节需要哪些安全措施呢。

  1. 首先是数据加密处理,由于云内数据最终运行在分布计算节点上,而前面讲分布计算节点的安全性不是百分百,因此万一有分布计算节点被入侵,被入侵节点内存中的用户数据将完全暴露。真的是一粒老鼠屎坏了一锅汤。所以云计算核心在分配计算任务前,数据需要经过加密。同样,在分布计算节点返回数据时,云计算核心也需要有相应的校验方式来确保数据没有被篡改。
  2. 其次是虚拟化安全性,整合后的资源通过虚拟化重新分配,而虚拟化的hypervisor有保证各虚拟系统/应用互不影响的义务。因此各虚拟系统/应用之间的通信将被划入本安全框架内,以防止某个虚拟系统或应用被破坏后,影响到云支持的其他服务的安全。就像电力系统中的区域性的电力控制能力,可以保证切断某个区域的电力,而不影响其他区域。在这方面,VMware和Citrix和安全供应商(reflex, Altor, Catbird)合作,提供了较为完善的hypervisor安全功能。
  3. 最后是对计算资源的保护,由于云计算核心对分布计算节点有很大的控制能力,而一旦云计算核心,比如任务分配系统,或是虚拟宿主等遭到入侵后,云内计算资源都面临很大的危险。因此需要在本环节加入主动防御功能,比如目前的蜜罐技术,通过设置诱饵来引诱入侵者主动攻击云内某些计算单元,以此避免有效计算单元的损失以及快速找出入侵者。

当然正如电力系统中的供电局一样,他需要负责协调两端电压以及灾害隔离来保证其两端以及自身的安全性。

 

最后,在计算能力的用户节点中,还是有可能面临一些由于云内安全不够或自身安全不够等引起的威胁。(注:这里的计算能力的用户节点不是指服务的最终用户,而是指使用云的那些服务。比如gmail的用户不是计算能力的用户节点,而gmail服务就是计算能力的用户节点了)

  1. 用户节点首先要有威胁隔离能力,这里的隔离是指,当使用同一个云的邻居用户被入侵后,通过该邻居对本用户节点产生的威胁被隔离。假如gmail服务和twitter服务都使用同一个云,当twitter的web服务虚拟主机被入侵后,想要通过twitter的web服务虚拟主机再入侵gmail的数据库虚拟主机的企图不会得逞。
  2. 防御宿主的攻击,宿主机在种种安全措施下虽然很安全,但是万一也被入侵的话,通过虚拟API就可以对用户节点造成很大的伤害。因此用户节点在给宿主机很大控制权的情况下,要保留拒绝管理的能力。当然这样的防御策略比较难制定,但却不可或缺。
  3. 灾害隔离能力,这是指在用户节点被破坏后,要有自动隔离不让本区域的灾害蔓延到其他用户节点,这就有点类似家庭电力系统的保险丝,通过保险丝来防止自家电力问题蔓延到邻居家或整栋建筑物内。

 

总之,云计算给安全领域带来了很多新的挑战,而这些挑战不可能由一家安全厂商或一个安全框架就能解决,因此云计算的安全性问题也给业界带来很多新的机遇。如果云计算在以上三个环节中能够保证高度安全性的话,云计算将会比传统计算具备更高的安全能力。就像电力革命之后的社会电力系统的安全性要远远高于某个企业内部维护的电力系统的安全性。