sohulinux

ARM kernel consolidation

翻译：李潇

你最近可能听说了内核中ARM架构存在的一些尴尬。鉴于ARM Linux的合并是Linaro特别要着手处理的问题之一，很自然你会想问“Linaro将怎么面对这个问题？” 所以当该话题成为了最近在匈牙利布达佩斯举行的Linaro开发者峰会的主旋律时，千万不要感到惊奇。

代码重复以及游离于主干开发流程之外的补丁，使得内核中的 ARM 部分尤其难以使用和开发。因此，Linaro正在合并代码并将代码推向主干。这将会让内核能更好的处理ARM板和SoCs。然而，ARM Linux内核合并并不是Linaro独自面对的问题，在整个ARM Linux内核社区，ARM Soc，ARM板和系统供应商也同样存在这些问题。因此，尽管我希望Linaro能起到关键作用，但最终的解决方案需要整个ARM社区的努力。另外很重要的一点是，这种努力只是一种尝试性的建议，而不是必须遵守的命令。

如果我们想要取得任何进步，我们必须从某些地方开始做起。一种极好的出发点是根据功能来组织ARM Linux内核代码而不是根据Soc/board实现。将有相同目标的代码聚集在一起将比较容易观察到相同的模式，甚至是相同的代码。比如，如今许多ARM SoCs用相似的“IP blocks”（比如I2C控制器），但是在相应的arch/arm/mach目录下每个SoC会提供一个完全不同的I2C驱动。我们期望在不同ARM板和SoCs上，相同硬件的“IP blocks”驱动能够合并为一个单独的驱动，并且该驱动能够使用相应IP block工作在任何系统上。在某些情况下，将一个给定的IP block与SoC或者ARM板连接起来有不同的方法，这样会带来些复杂度，但这样的复杂度总是可以被搞定的。

这样又出来了一个问题，相似的代码应该移到哪儿去。大家都同意的回答是，不应当移到arch/arm目录下。驱动理所当然要放到顶层drivers目录树的相应子目录下面。另外，ARM SoCs有内置多种不同的设备，从触摸屏到GPS接收器，再到加速感应器，而且新型设备还会不断出现。所以某些时候，将代码移动到某个驱动分类也不完全合适，而最好是在drivers树目录中创建一个新的分类。

但对非驱动代码该怎么办呢？它应该放在哪？看一看以下例子应该会有启发：（1）Jeremy Kerr，Russell King，Thomas Gleixner，还有很多其他人一直在开发的struct clk代码。（2）Grant Likely领导的device-tree代码。（3）Thomas Gleixner一直在开发的通用中断的芯片实现。

struct clk代码是由许多SoCs和ARM板里elaborate clock trees受到启发的。这些树在其他地方会用到，在性能和能源效率方面权衡，根据SoC或者ARM板上单个设备的需要作出设置。struct clk代码在提供插件去适应指定SoC或ARM板的同时，还允许这些树以通用的格式表示。通用中断芯片实现也有相似规则，但它跟时钟树无关，而是跟中断分布有关。

设备树的目的是用来允许通过数据而不是代码来表示ARM板的硬件配置，这能够减轻创建一个在不同ARM板上启动的单一Linux内核二进制的任务压力。设备树基础架构补丁已经在近期被Russell King接受，这说明从特定ARM板代码到设备树描述的转变将开始。

struct clk代码已经被同时用在了ARM和SH CPU架构中，所以它不是只对ARM适用的，而是更核心的Linux内核代码。同样的，设备树代码也不是只对ARM适用的，它同样被PowerPC, Microblaze和SPARC架构用到，甚至被x86架构用到。因此设备树也是Linux的核心内核代码。虚拟中断使用的更广泛，在所有CPU架构中都很普遍。这给我的启示是ARM内核代码合并不一定要限制在ARM上。事实上，一段特定代码支持的架构越多，愿意对它贡献代码和测试的开发者就会越多，这段代码就会越健壮，越具有可维护性。

当然，也需要有一些只针对ARM的代码，但是这些代码最终会限制为ARM核心架构代码和ARM SoC核心架构代码。而且，ARM SoC核心代码最终会演变为由针对核心Linux内核框架的小插件组成，这将会极大减轻新ARM板和SoCs的开发和维护。

很容易将这些做法写出来，但真正去实现它却是另外一回事。毕竟，尽管有一大批极有天赋和激情的ARM开发和维护人员，但是其中很多是ARM新手，对Linux内核也不熟，自然也不知道新代码该放在哪里。这些人可能很容易继续将他们的大部分代码放在SoC和ARM板子目录下，这将使得现存的ARM Linux内核难题继续存在。

解决方案的一部分是增加文档，特别是指导ARM驱动和ARM板端口开发的文档。Deepak Saxena，这位Linaro内核工作组的新领导者，即将开始这项工作。虽然只有当真正读到它时，文档才会发挥作用。但幸运的是，正如在计算机科学里任何问题似乎都可以通过增加额外的间接层来解决一样，任何维护上的问题似乎也都可以通过增加额外的git树和维护人员来解决。这些维护者将会帮助生成通用代码，在代码可用后自然也就成为文档的开发人员。

可以使用Nicolas Pitre现成的Linaro内核git树。然而，Nicola的git树是integration tree，就是说将最新的ARM相关代码合并到一个静态的主线版本。相反，maintainership tree面向的是计划合并进入上游的补丁，这些补丁是以下一个主流发布候选版本为根据的。如果我们用单一的git树来处理整合和维护，那我们要么不必要的将不相关的核心内核bug暴露给用户，要么我们不能足够紧密得跟踪主线内核用以维护，这将使得在每个合并窗口期开始的那一小段时间内，强制进行一个完整的rebase和测试期。

当然，理论上我们可以在同一个git树上有维护和整合分支，但是将这两个很不同的功能分开到不同的git树可能是初期最好的选择。

这个新的git树(公布于五月18)将在每一个参与的ARM子架构至少有一个分支，并且这些分支将不会受到rebase合并，这让在该git树上的开发变得容易。遵循惯例，参与ARM子架构的维护者将宣布该维护工作组发送该git树的 pull request。同样，遵循惯例，所有分支的合并请求将会发送到Stephen Rothwell的 -next 分支。这些分支也有可能通过Russell King的ARM树，独立推送给Linus Torvalds。

每个分支独立推送给Linus，这看起来很令人奇怪，但Linus的确希望看到由此产生的冲突。这样的冲突可能会帮助Linus找到需要他注意的地方。

无疑，这个新的git树将不会限制在Linaro内部，但也不仅仅给Linaro之外的同仁使用。我会非常高兴地看到一些Linaro之外的维护者表示有兴趣参与进来。

布达佩斯的会议推举出了这个git树的维护组成员，即Arnd Bergmann, Nicolas Pitre和Marc Zyngier,另外还有Thomas Gleixner提供帮助。Russell King当然也会拥有对该树的写权限。这个树将及时启动以应对2.6.41合并窗口期。该计划打算从小处开始不断迭代向前进化而不是一开始就设计一个完美模型。

正如文章开始提到的，这种努力是一种实验，而不是必须遵守的命令。尽管这个建议性的实验不能期望解决每个和任何ARM Linux问题，但他们将提供一个好的开始。每一点帮助，每一次清理释放一些时间来启动下一次清理。有理由希望这份努力会帮助减少无数的毫无意义的并让Linus Torvalds在上个月动怒的平台代码

sohulinux 第二期

1. Stable pages
2. Ftrace, perf, and the tracing ABI
3. Scale Fail (part 1)

本来还有一篇，感觉质量一般，就算了吧

Scale Fail (part 1)

http://lwn.net/Articles/441790/
By Josh Berkus
May 6, 2011
翻译：王鑫

让我告诉你们一个秘密：我从来不去修正数据库，我去修正程序。

许多公司总是请我去“修正数据库”，因为他们总是认为造成他们性能和宕机的问题是出在数据库上。其实，数据库很少出现问题。可伸缩性糟糕的应用总是由一系列错误的管理决策所造成的。事实上，这些错误的决策是如此常见以致于可被称之为反面模式。

">www.job108.com/App/show_article.aspx?m=00276AEAA000058F6[/geshifilter-code]
　
我在上一次的MySQL会议上做了一点关于反面模式的讨论，先去看看再继续来讨论。当你已经看过了这个五分钟的小短片（希望你笑了），下面介绍几个解释怎样识别和避免反面模式的细节。

Trendiness

这是不是听起来就好像你的CTO一样？这可是源于一次我真实的对话。它说明了越来越多的技术负责人开始思考一个问题：比起站点是否仍在运营或者公司正常运转而言，他们更关注个人形象和职业。如果你开始在一些基础会议上听到诸如“流行”、“热点”、“前沿”、“最新技术”或者“流行产品”，那么你就得当心了。频频引用杂志上的调查结果或者产业趋势是另外一个危险信号。

Scaling 应用本质上就是关于资源管理和重复性的日常工作。这意味着使用你的员工熟悉的，已经被证实为可靠的，并且就是按照你所想的而设计的技术。热门新特性不如无人值守的可靠运营。web世界里总把一个个崭新的技术推到前台，尽管它们匮乏文档、不稳定、不能同其它组件集成，并且充满各种漏洞。

还有另一种趋势值得被注意，常常听到这样的言论，“如果Google或者Facebook在做某件事情，那它一定就是正确的选择。”首先，除非你的应用程序或平台同他们的非常类似，那么对他们而言是正确选择的事情不一定对你也是正确的选择。

此外，并不是每件Google和Facebook做的事情，如果让他们从来一遍他们还会去做。像其他的公司一样，这些顶级的互联网公司也做过错误的技术决策。所以当你将要模仿那些巨头们的行为时，请首先确定一下他们的员工对这个技术的看法。

No metrics

　
Scaling 应用是一个数学问题。如果一个用户在web服务器上消耗X个CPU时间，那么你想支持100,000个用户的并发访问时，你需要多少个web服务器呢？如果数据库每天增长Y，而其中Z%的数据是“active”，那么这些常用数据的大小超过RAM的容量需要多少时间？

明显地，你至少需要知道X、Y、Z的近似值才能对此类问题作出估计。如果你在做scale，你应该考虑你的应用程序栈的每一个部分，从存储硬件到JavaScript。而那个你忘了监控的东西很有可能就是让你整个站点挂掉的原因。近年来的大多数软件都有一些监控它们性能的方法，软件不应该成为你规避的部分。

尽管这是一个常识，我们的客户中仍然有相当多的一部分仅仅用Nagios监控它们的硬件。这意味着当出现响应时间的问题或者其它一些超过Nagios能力范围内的问题时，他们无法去诊断到底是什么原因引起这种问题的，而且到头来，他们总是去修正错误的部分。

更糟的是，如果你没有你的应用程序实际消耗资源的统计的话，那么你就不知道当你去扩充你的站点时，你需要多少、哪种类型的服务器。那意味着你将对某些组件进行大规模地重建，并且花费两倍的金钱，而其它部分只能缩减。

有多少个公司没有测量数据，或者跳过这个问题，他们是怎么做决策的？呃……

Barn door decision making

　
缺乏数据的情况下，员工一般都根据他们的经验来排解故障，而这往往是错误的。尤其当出现突发事件时，一般都会去解决上次出过问题的那个部分。当然，上次出问题的地方，不一定是这次造成这次问题的原因。

当你计划扩容的时候，这种思想会更糟糕。我见过许多IT员工依靠他们上一个项目的经验甚至上一份工作的经验来购买设备，提供服务，配置软硬件，部署网络。这意味着，当现有应用程序的可用资源不能够完全匹配应用程序的需求时，你要么为此提供更多，要么挂掉。

当然你应该从你的经验中学习。但是你应该学些合适的教训，比如“不要指望VPN总是连通的”。不要误用知识，比如把应用到图片站点的cache策略应用到在线银行站点上来。反例通常类似如下的格式的断言：

•  “当我在XXX（原来的公司名）的时候……”
•  “当我们原来遇到XXX（其实并不是很相似的问题）的时候，我们用XXX（某种软件或技术）”
•  “XXX（差别很大的项目）使用XXX（某种软件或技术），因此我们也改使用它。”

(For non-native English speakers, "barn door" refers to the expression "closing the barn door after the horses have run away")

下面我们检讨程序设计中的问题

Single-threaded programming

　
并行处理的框架对大多数开发者来说都是一个挑战。我见过上百次这样的故事了：一个开发者把他的代码写成了单线程的形式，然后他在自己的笔记本上，在单用户单并发的情况下测试，之后他把这份代码部署到了有200个服务器的站点上，然后这个站点挂了。

单线程是可扩展性的敌人。你的应用程序的任何一部分，如果限制了同一时刻并发执行同样代码的能力，那意味着把你限制在单机单核的吞吐量上。我并不是在这里讲应用程序代码中关于互斥的部分，尽管那也可能很糟糕。我在讨论的是由于等待某个独占锁式的组件而阻塞了整个应用程序的设计问题。

比如，一个入门新手常犯的错误就是把所有的异步任务放到一个单向队列里去。这样整个应用都受限于这个队列处理的速度。其它常见的错误包括：frequently updated single-row "status" table, explicit locking of common resources, and total ignorance of which actions in one's programming language, framework, or database require exclusive locks on pages in memory.

我当前工作的应用是一个分布式的，拥有240台服务器的数据处理集群。然而，把数据分块交给服务器运算的部分是一个只跑在一台服务器的单进程程序。于是整个云每分钟只能处理4000个任务，75%的时间是空闲的

更糟糕的例子是我以前咨询过的一个很流行的体育站点。赛事信息是从互联网上其它的服务获取的，更新信息的时候它会在数据库事务里保持一个独占锁，然后等待远程服务器响应。客户无法明白为什么增加的应用服务器越多，用户的超时就越严重。

设计可伸缩的应用之前，问问自己："how would this work if 100 users were doing it simultaneously? 1000? 1,000,000?"。学习一门函数式语言或者 map/reduce. 这会训练你思考并行的能力

=============
等待下集

谁在维护RPM? (2011版)

Who maintains RPM? (2011 edition)
By Jonathan Corbet
May 3, 2011
翻译：李凯

早在2006年，LWN 就讲述过关于 RPM 这个软件维护过程的复杂故事。考虑到该软件对于所有基于 RPM 的发行版的重要性，RPM 缺乏一个如何进行维护的清晰描述确实很令人沮丧。当年晚些时候，Fedora工程宣布成立一个新的，社区驱动的 rpm 项目。从那以后，这件事情就悄悄的进行着，但是最近的一些事件表明，rpm的故事还没有走到尽头。

上述提到的rpm工程运转在rpm.org上。4.9版本已经在三月初发布了。该代码也在积极的维护中，同时可以看到新增加的一些小小的特征。但是这个项目对是否有一个大的发展计划并没有发出任何实质的信号。只有少数的几个提交者为代码仓库工作；他们中的绝大多数人是为RedHat工作的。从所有迹象来看，rpm至少一半是维护模式。

但是rpm.org不是唯一的 RPM 站点，还有一个fork项目rpm5.org。这个版本主要由Jeff Johnson来维护，他之前是Red Hat的雇员，在公司之外发起了这个项目，希望创建一个更好的 RPM。这个版本增加了更广泛的可移植性，还有一些特性比如新的压缩格式和许多其他的一些东西（rpm5 并没有一个完整的特性列表，俺也懒得在ChangeLog上搜寻显要的变化）。一个重要的特征是包的事务管理（也叫做“RPM ACID”），其思想是确保任何rpm操作，要么成功要么完全失败，无论中间过程发生了什么。依照Jeff所说，rpm4操作中如果被杀掉，可使整个系统被损坏；但rpm5消除了这种可能性。

RPM5 fork可以说已经有了更多的发展以及增加了一些有趣的新功能。尽管如此，它仍然是一个相对模糊地项目；它已经被诸如 Alt Linux，ArkLinux 和 Unity Linux 所选择，但还没有得到较大的 distributor 的重点考虑。然而最近几个月这些情况已经有了变化：在 Mandriva 2011 plans中就包括了切换至rpm5。这已经为这个fork带来了更多的关注并产生了一些有趣的结果。

并不是在Mandriva阵营里的每个人都认为这个切换是一个好主意。早在去年11月份，Evgeni Dadonov就开始对这种变化背后的原因展开讨论：

（据我所知，Fedora/RedHat/CentOS and SUSE/OpenSUSE 等主要的供应商都支持RPM4，Alt Linux and Unity Linux使用RPM5.  RPM4主要的特征是稳定，以及众所周知的那些长期悬而未解决的问题以及它的行为表现。RPM5正在不断的发展中，它有很多特点，但没有太多的安装的基础。）

不论是拥护还是反对，许多人就这个问题进行相当激烈的讨论，有时还会产生一些不愉快。转向 RPM5 的决定似乎是基于若干考虑的。某些新的功能对Mandriva很有吸引力。开发RPM5的团体看起来似乎比RPM4的团体更加的活跃、开放；rpm4主要由RedHat主导，相对比较封闭。Mandriva 有一堆没有被 RPM4 接受的补丁，现在可以 upstream 到 RPM5。与其他大型基于RPM的发行版保持 RPM 包的兼容性只是一个虚幻的概念，每个发行版都根据自己的需求对rpm4进行大量的修补，所有发行版几乎都无法安装非本发行版的其它 RPM 包装（译者：所以 RPM5 不兼容也不是大不了的事情）。重要的是Mandriva的包维护者Per Øyvind Karlsen希望采用其它的模式：

（我已经说的很清楚了，我已经计划去维护rpm5，我是一个维护者，有最好的知识。如果你更新到我的测试版本里的话，会体会这种改变不会对你产生消极影响。我是包的维护者，它不应该对别人造成不便。我觉得我应该做出个关于是否应该继续维护已经被彻底打乱了的rpm.org版本的决定，它陷入补丁中，并痛苦的重新生成每一个版本。）

Per Øyvind断言，“这种改变不会对你产生消极影响”。这个断言没有变成现实，从此以后，Mandriva的 cooker 邮件列表就一直被关于rpm5相关问题的讨论占据。其他小的系统变化，例如 systemd 的改变，被湮灭在滔滔的 RPM5 讨论中。这种类型的切换一直都不容易，与Mandriva的更高级别的包管理工具的整合使得整个大工程愈发的复杂化。去适应 Mandriva 这样一个巨大复杂的发行版是 RPM5 不可避免的成长之痛。

必须指出的是，很明显 Jeff 花了大量时间支持 Mandriva 的这个计划。人们很容易得到这么个印象，他被公司聘用作为这个项目的一部分。问题一个个被提出，Jeff 一个个努力解决。很少有开发项目拥有这样努力去支持它的用户，即使是高知名度的牛人也难以如此投入；Jeff已经真正的为Mandriva服务。

这种支持在四月底的时候有些动摇，Jeff突然宣布，rpm5的邮件列表（以及许多其他的网站内容）归档已经被撤下。在被质疑为什么会发生这样的情况时，他的反应非常过火。事后他自己承认，他想尽快停止这种讨论。这个网站已经重新上线，包括一个重定向到rpm5.org的rpm6.org。

这是怎么回事远没有明朗，但从Jeff指责一名Mandriva的前开发者“应该对破坏rpm5品牌负责”的邮件里可得到一些暗示。他真的对于处理报道的问题以及抱怨有关rpm5的事情感到疲惫，而其中许多确实与rpm5的问题无关。大部分问题貌似是由于 Mageia（a fork of Mandriva）没有随着Mandriva迁移RPM5所至。Mageia的立场，正如AnneNicola描述的那样，似乎是合理的：Mageia的开发者为了保证紧跟 Mandriva 发行节奏就已经忙不过来了。鉴于所有需要所做的事，把精力投入到一个低级别的包管理器系统的变化看起来似乎不是最好的主意。

这样看来，依然有些坏的血液在Mandriva和Mageia阵营中。有些迹象表明，相比较公共的列表而言，私下的讨论不那么友好，Jeff和rpm5很可能在那里被议论。至少，可以从类似的评论中可能得的一条结论：

（你已经花了数月时间推销rpm5但并不成功。RPM5被评为惨败...被很多你绝不喜欢的词语诅咒。What you don't like has nothing whatsoever to do with this "tourist with camera" wandering the dungeons hacking on RPM.

我可以告诉你，从我的第一手经验而言，fork 是对时间和精力的巨大浪费。我还可以说，Mandriva 和 Mageia 的相似之处比相异处更多。我强烈建议你该干嘛干嘛去）

自从那以后，最糟糕的事情已经过去了，Jeff已经回来讨论有关使rpm5工作的更好的话题了。这个事件已经让某些在Mandriva社区中的同志警醒，开始担忧2011版本建设基础。

观看这里讲发生什么是一件有趣的事情。现在Mandriva看起来似乎很好的承受了rpm5的过渡，一切貌似已经稳定下来了。如果RPM5在2011版中表现的比较好，其它发行版的用户将会问，为什么会我们还坚持用"旧的版本"；反之，其它发行版也可能看到Mandriva经历的痛苦，以及一个不那么如意的结果，他们就继续快乐的使用相对无聊的RPM4好了。

无论哪种方式，好戏还没有完全结束呢。

PostgreSQL 9.1的新特性

New features in PostgreSQL 9.1
by Josh Berkus
May 2, 2011
翻译：王鑫

著名的开源关系型数据库PostgreSQL本年度的发行版，也就是PostgreSQL 9.1的第一个beta版本，于五月二号正式出炉。而新版本所包含的许多新特性肯定会令世界上的数据库发烧友们欣喜若狂的。新特性如此之多，我们肯定不能在这篇文章中全部介绍，因此我挑选了四个比较有意思的新特性呈现给大家：

事务控制的同步复制

去年，PostgreSQL 9.0首次在PostgreSQL中引入了“异步二进制复制”。基于这个概念，9.1版本也包含了一个同步复制的选项。“同步复制”意味着直到被主服务器和复制服务器均接收完事务时，事务才会返回给应用程序。这点就确保了即便在主服务器永久下线的情况下，任何已提交事务的数据都不会丢失。

通过NTT的开源和2ndQuadrant的努力，经过长达三年的开发，终于使这个特性最终达到顶峰，而这将使得日本的通信巨头NTT最终会把他们的大多数的Oracle服务器替换为PostgreSQL。PostgreSQL的集群项目PostgresXC是这个替换工作的另外一部分。

对于同步复制来说，事务在返回前需要被写到两个服务器的磁盘上，因此会在响应时间上带来很大的损失。为了缓解这种情况，PostgreSQL除了像其它数据库系统一样提供同步复制功能外，还额外提供一个可以基于每一次事务提交而做出同步或异步复制的控制功能。这将使应用开发者通过把一些不可丢失的关键数据（比如财务交易）和那些响应时间上要求高的不太关键的数据区分开，来优化系统系统的性能。

每一个复制节点（或“standby”）连接主机的时候，都会在它的recovery.conf文件中给自己指定一个名称：

    primary_conninfo = 'host=master01 user=replicator application_name=replica1'

然后主机会在它的postgresql.conf文件中为同步复制机设置一个优先级列表：

    synchronous_standby_names = 'replica1'

然后你就可以以同步或异步的方式提交事务了：

    -- commit synchronously to the standby
    SET synchronous_commit = 'on';
    UPDATE user_balance SET balance = 573.29 WHERE user_id = 40021;
    -- messages are not important, send asynchronously to the standby
    SET synchronous_commit = 'local';
    INSERT INTO user_messages VALUES ( 40021, 57843, 'HI!' );

PostgreSQL也支持一个同步复制节点的优先级列表，也因此支持更高可用性的配置。新的pg_stat_replication数据库视图允许数据库管理员(DBAs)监控数据库复制节点的状态，而其他的管理设置控制如果复制节点离线时做什么。PostgreSQL计划在未来的版本中支持不同的同步模式，比如拥有“quorum”同步的能力。后者是为了在改善相应时间的同时而不降低数据的完整性，即“同步五分之二的服务器”的复制。

Unlogged 表

迅速风靡的非持久型“NoSQL”数据库，比如Redis和MongoDB以及信誉卓著的Memcached，已经证明了存在着这样一类数据——比起响应时间来，崩溃之后的数据损失显得并不是那么很重要。EnterpriseDB开发者Robert Haas在PostgreSQL中加入了一个专门处理此类数据的功能：unlogged 表。

词语“unlogged”主要是参照保证了持久性写的transaction log而得出来的。如果数据库服务器关闭再重启后，unlogged表将被清空。然而，不像往磁盘中写数据那样漫长，你写到unlogged表的速度比你往持久性存储的表写数据的速度快20倍。你也可以把它想象成为一个全局的临时表或者“内存表”。

unlogged表旨在存储大容量但不是很有价值的数据。比如，许多PostgreSQL用户当前登录网站的用户会话记录在Memcached。unlogged表在数据仓库批处理过程中用来存储大量原始装载数据同样也是十分有效的。这些用途通过在用户的应用程序栈中减少单纯使用数据库目的的数据库来使PostgreSQL用户变得更轻松。

SELinux集成
另一个经过多年开发而第一次出现在PostgreSQL 9.1中的新特性是PostgreSQL和 SELinux的数据访问控制的一致性。NEC程序员Kaigai Kohei花了三年的时间开发了SE-PostgreSQL，它把label-based的数据访问规则的概念集成到了PostgreSQL之中。PostgreSQL是第一个拥有这个级别集成度的SQL数据库系统。

这个特性目的在于高安全性的环境，甚至于数据库管理员都对数据的访问有限制，比如国家安全数据库。安全策略是构建在系统或者网络层的，而通过SELinux现在可以被应用在表、视图、函数、列等等的权限控制上。这就使得不管这个数据是存放在文件中还是存放在数据库中，我们只需构建一个一致性安全策略就可以了。

LWN的长期读者一定注意到了SE-PostgreSQL在集成到主流的PostgreSQL时有许多的麻烦。其实，9.1 beta版本中的SE-PostgreSQL相对于原来的版本来说，基本上是完全重写的。首先，Kohei在其他黑客们的帮助下重写了所有的权限查询调用，加入了SELinux hook，这个特性可以在PostgreSQL编译的时候选择是否被启用。如果是non-SE-enabled模式就不会有任何SELinux的影响。第二，SE-PostgreSQL所有的管理和工具都移到了一个可选的加载模块当中。

最后，由于难以实现，某些控制从Mandatory Access Control中删除了。这其中主要的就是行级的访问控制，因为在如何实现它这方面还存在着许多未解决的理论问题。当然，这意味着Kohei还有许多工作要做。

扩展和PGXN
谈论可选模块时，PostgreSQL一个主要优势就是它的扩展能力。用户和开发者定义了数据类型、操作、函数并且集成到一起来支持许多类型的特定数据，包括基因，库存，数学，天文学，时间序列，地质学等数据。还有很多插件，比如支持队列的集成，同其它数据库系统兼容，和许多实验性的新特性。PostgreSQL中最著名的插件可能就要数PostGIS地理数据库了。

然而，PostgreSQL的大多数插件都很难被找到、安装、备份或者升级，这就限制了它们的使用，有时甚至使用户不得不重复开发它们好几次。这个情况在9.1中改变了。

首先，2ndQuadrant的Dimitri Fontaine创建了一个打包的概念，而这在PostgreSQL 9.1中被称之为扩展。通过把一系列的数据库对象打包为一个扩展，插件的增删管理，以及最重要的升级，都变成了轻松的脚本化工作。用户甚至可以根据机构内的数据库的定制需要来创建自己的扩展。

第二，PostgreSQL专家David Wheeler创建了PGXN(PostgreSQL EXtension Network)，“PostgreSQL扩展网络”。PGXN是仿照编程语言的扩展仓库，比如perl的CPAN和Ruby GEMs。PGXN给PostgreSQL用户提供了一个搜索和下载那些未同核心数据库一同发布的PostgreSQL插件的中心。当前正在开发的是一个包含了依赖跟踪的下载和安装一体化的工具，就像CPAN和apt-get一样。

====
后面有部分内容没有完成翻译，感兴趣可去原文自行参考：http://lwn.net/Articles/440666/

Raw events and the perf ABI

http://lwn.net/Articles/441209/
By Jonathan Corbet
May 3, 2011
翻译：刘晓佳

====
The perf events subsystem often looks like it's on the path to take over the kernel; there is a great deal of development activity there, and it has become a sort of generalized event reporting mechanism. But the original purpose of perf events was to provide access to the performance monitoring counters made available by the hardware, and it is still used to that end. The merging of perf was a bit of a hard pill for users of alternative performance monitoring tools to swallow, but they have mostly done so. The recent discussion on "offcore" events shows that there are still some things to argue about in this area, even if everybody seems likely to get what they want in the end.

perf events 子系统貌似将在内核中全面应用：相关的开发非常活跃，并且已经形成一种通用的事件报告机制。不过 perf events 的原始设计是为了访问硬件所提供的性能监控计数器，而且现在仍然被用于该用途。对于使用其它性能监控部件的开发者，转向到 perf 子系统是一剂难以吞咽的苦药，好在基本上都转的差不多了。但最近关于 "offcore" events 的讨论，显示该领域仍然存在争议，even if everybody seems likely to get what they want in the end.

====
The performance monitoring unit (PMU) is normally associated with the CPU; each processor has its own PMU for monitoring its own specific events. Some newer processors (such as Intel's Nehalem series) also provide a PMU which is not tied to any CPU; in the Nehalem case it's part of the "uncore" which handles memory access at the package level. The off-core PMU has a viewpoint which allows it to provide a better picture of the overall memory behavior of the system, so there is interest in gaining access to events from that PMU. Current kernels, though, do not provide access to these offcore events.

性能监控单元（PMU）通常是和CPU联系在一起的。每个处理器都有自己的 PMU 用以监控自己的特定事件。一些最新的处理器（如Intel的 Nehalem系列）还提供了一个没有和任何CPU关联的 PMU，该例子里，PMU 是 "uncore" 的一部分，负责在包层面来处理内存访问的性能计数。这个 offcore PMU 能够为系统的内存行为提供更好的全貌，从这个 PMU 获得事件的访问会很有趣。然而，当前版本的内核并不提供对这些 offcore 事件的访问。

====
For a while, the 2.6.39-rc kernel did provide access to these events, following the merging of a patch by Andi Kleen in March. One piece that was missing, though, was a patch to the user-space perf tool to provide access to this functionality. There was an attempt to merge that piece toward the end of April, but it did not yield the desired results; rather than merge the additional change, perf maintainer Ingo Molnar removed the ability to access offcore events entirely.

依赖于 Andi Kleen 在三月份提供的一个补丁，2.6.39rc 版内核提供了这些事件的访问方式。有人尝试在四月末提供一个让用户空间的 perf 工具来访问该功能的补丁，但没有完成。因为任何相关的改变已经没有意义，perf维护者Ingo Molnar将访问 offcore 事件的能力全部移除了。

====
Needless to say, that action has led to some unhappiness in the perf user community; there are developers who had already been making use of those events. Normally, breaking things in this way would be considered a regression, and the patch would be backed out again. But, since this functionality never appeared in a released kernel, it cannot really be called a regression. That, of course, is part of the point of removing the feature now.

自然不必说，这种行为必然会导致 perf 开发社区的不快；有些开发者已经在用那些事件了。通常，这会被视为一个 regression，相关最新补丁被迫回滚。但是由于这些功能并未出现在正式发行中，所以也不能报告 bug 说发生了 regression，只是我们移除了一个特性而已。

====
Ingo's complaint is straightforward: the interface to these events was too low-level and too difficult to use. The rejected perf patch had an example command which looked like:

    perf stat -e r1b7:20ff -a sleep 1

Non-expert readers may, indeed, be forgiven for not immediately understanding that this command would monitor access to remote DRAM - memory which is hosted on a different socket. Ingo asserted that the feature should be more easily used, perhaps with a command like (from the patch removing the feature):

    perf record -e dram-remote ./myapp

Ingo抱怨道，这些事件的接口太底层了，用起来特别难。被移除的perf补丁有一个命令的例子：

    perf stat -e r1b7:20ff -a sleep 1

对非专家读者来说，无法理解这条命令是指示监控 remote DRAM（memory which is hosted on a different socket，貌似是关联在其它CPU插槽上的内存）访问。Ingo认为这些特性应该更容易使用才对，比如像下面这条命令：

    perf record -e dram-remote ./myapp

====
He also said:

But this kind of usability is absolutely unacceptable - users should not be expected to type in magic, CPU and model specific incantations to get access to useful hardware functionality.
The proper solution is to expose useful offcore functionality via generalized events - that way users do not have to care which specific CPU model they are using, they can use the conceptual event and not some model specific quirky hexa number.

他同时说道，这种不易用性绝对无法令人接受。用户不应该被期望能够通过键入魔术般地、CPU级的、特定模式的咒语去访问有用的硬件功能。合适的方案是通过广义的事件来揭示 offcore 功能。这种方式下，用户不必去关心自己用的CPU模式，可以使用集中的事件而不是靠离奇的十六进制数指定的模式。

====
The key is the call for "generalized events" which are mapped, within the kernel, onto whatever counters the currently-running hardware uses to obtain that information. Users need not worry about the exact type of processor they are running on, and they need not dig out the data sheet to figure out what numbers will yield the results they want.

关键是定义出广义事件("generalized events")，它们在内核中被映射为计数器，正在运行的硬件用之来获得那些信息。用户不用去关心他们运行的处理器的型号，不必去通过挖掘数据表来确定出哪些数字将给出他们想要的结果。

====
Criticism of this move has taken a few forms. Generalized events, it is said, are a fine thing to have, but they can never reflect all of the weird, hardware-specific counters that each processor may provide. These events should also be managed in user space where there is more flexibility and no need to bloat the kernel. There were some complaints about how some of the existing generalized events have not always been implemented correctly on all architectures. And, they say, there will always be people who want to know what's in a specific hardware counter without having the kernel trying to generalize it away from them. As Vince Weaver put it:

Blocking access to raw events is the wrong idea. If anything, the whole "generic events" thing in the kernel should be ditched. Wrong events are used at times (see AMD branch events a few releases back, now Nehalem cache events). This all belongs in userspace, as was pointed out at the start. The kernel has no business telling users which perf events are interesting, or limiting them!

批评主义者已经采取了一些行为。广义事件，是一个很好的东西，但是却无法反应所有的怪异的，每个处理器可以提供的特定硬件的计数器。这些事件应该在用户空间被管理，这样会更灵活，而且不必使内核膨胀。有些抱怨是关于为何已经存在的一部分广义事件并不能在所有的体系结构下总是被正确执行。而且，总是有人想去直接使用特定的硬件计数器而不是内核提供的抽象层。正如Vince Weaver所说：

阻止访问 raw events 并不是个好主意，甚至整个内核中的通用事件都应该被丢弃。（现况导致了）时而出现不合适的事件应用（比如以前一些版本里 AMD 的 branch events，现在的 Nehalem的 cache events）。这些都应该在最开始就明确是属于用户空间的事件。内核没必要告诉用户哪个 perf events 是感兴趣的，或者限制它们。

====
Ingo's response is that the knowledge and techniques around performance monitoring should be concentrated in one place:

Well, the thing is, i think users are helped most if we add useful, highlevel PMU features added and not just an opaque raw event pass-through engine. The problem with lowlevel raw ABIs is that the tool space fragments into a zillion small hacks and there's no good concentration of know-how. I'd like the art of performance measurement to be generalized out, as well as it can be.

Ingo回应到性能监控的相关知识和技能应该集中在一个地方：

我认为用户需要我们增加有用的，高层的 PMU 特征，而不仅仅是提供不透明原始事件传递的引擎。仅有最底层的原始ABIs的问题是，这将功能分割成无数的小的hack，而没有一种好的集中方式。我希望性能衡量的艺术更一般化，而且也可以做到。

====
Vince, meanwhile, went on to claim that perf was a reinvention of the wheel which has ignored a lot of the experience built into its predecessors. There are, it seems, still some scars from that series of events. Thomas Gleixner disagreed with the claim that perf is an exercise in wheel reinvention, but he did say that he thought the raw events should be made available:

The problem at hand which ignited this flame war is definitely borderline and I don't agree with Ingo that it should not made be available right now in the raw form. That's an hardware enablement feature which can be useful even if tools/perf has not support for it and we have no generalized event for it. That's two different stories. perf has always allowed to use raw events and I don't see a reason why we should not do that in this case if it enables a subset of the perf userbase to make use of it.

Vince同时宣称perf是一个重复的革新，它忽略了前辈的大量的经验。似乎看起来仍旧有些那些一系列事件的疤痕。Thomas Gleixner不同意这种perf是重复创新的实践，但是他也认为原始事件应该可被用（译者注：从ABI的层面被暴露出来？）：

The problem at hand which ignited this flame war is definitely borderline，我并不同意 Ingo 所说没有必要提供原始事件接口。那是一个有用的硬件可实施的特性，即使perf 还没有支持它，而且我们也没有普遍的事件支持它。那是两种不同的故事。perf总是允许使用原始事件而且我也并没有看到一个我们不应该那样做的理由，如果它使得一部分用户群体利用它。

====
It turns out that Ingo is fine with raw events too. His stated concern is that access to raw events should not be the primary means by which most users gain access to those performance counters. So he is blocking the availability of those events for now for two reasons. One of those is that he wants the generalized mode of access to be available first so that users will see it as the normal way to access offcore events. If there is never any need to figure out hexadecimal incantations, many user-space developers will never bother; as a result, their commands and code should eventually work on other processors as well.

The other reason for blocking raw events now is that, as the interface to these events is thought through, the ABI by which they are exposed to user space may need to change. Releasing the initial ABI in a stable kernel seems almost certain to cement it in place, given that people were already using it. By deferring these events for one cycle (somebody will certainly come up with a way to export them in 2.6.40), he hopes to avoid being stuck with a second-rate interface which has to be supported forever.

讨论最后，Ingo 也认为原始事件很好，不过他的立场是大多数用户访问性能计数器不应该以访问 raw events 作为主要手段。现在他阻止这些事件的可获得性基于两个原因。一个是他想首先实现通用的访问模式，这样用户能以很普通的方式来访问 offcore 事件。如果没有任何必要去理解十六进制的咒语，许多用户层面的开发者将不再烦恼。同时他们的命令和代码也能在其他处理器上也正常工作。

另一个原因是，当这些事件的接口彻底地想清楚时，暴露给用户层的ABI需要去改变。在稳定的内核版本上发行第一版ABI几乎肯定要在某些方面加强，然而考虑到用户已经在用它了。靠推迟这些事件一个周期（2.6.40版），他希望避免推出一个二流的接口却不得不永远支持它。

====
There can be no doubt that managing this feature in this way makes life harder for some developers. The kernel process can be obnoxious to deal with at times. But the hope is that doing things this way will lead to a kernel that everybody is happier with five years from now. If things work out that way, most of us can deal with a bit of frustration and a one-cycle delay now.

无疑以这种方式来管理这个特性对一些开发者来说很难。Linux 内核开发过程的处理难免可恶。这种方式是希望五年之后有一个每个人都很满意的内核。

开始 sohulinux 计划

无数人在做类似的事情，从严复陈独秀起就是这样了

我希望搜狐的技术团队能更开放一点儿，离开源社区更近一点，大家研究的东西稍微深那么一点儿

这是一个挺麻烦的过程，不仅仅自个儿要努力，还需要得到别人的认同。。。形成良好的正反馈，才是长久之路

于是我决定组织我的训练营翻译 LWN.net 上的文章，我觉得这上面的东西绝对符合开源社区口味，内容基本还挺有深度，而且一周一期，非常与时俱进。

这就是 sohulinux.blog.sohu.com，请大家订阅.. 当然最开始一段时间我自己也会不断刊发

希望最后成长出若干个牛逼的搜狐技术博客出来，我就去做搜狐最本行的职业，一个编辑吧，哈