博客

Brother Louie

周日开车的时候，从收音机里听到这首歌。

我靠，实在是太老了，太怀旧了。。下回去卡拉OK完全可以尝试

sohulinux 第七期

本周内容只有一篇：新的连续内存分配器

此外，在网上也找到了一个同志，定期发布 lwn/h-online/phoronix/... 等等的内容摘要的，推荐一下raise_sail (姓名: Rover Yu)

接下来，计划慢慢增加原创内容

新的连续内存分配器

翻译：王鑫/李潇

关于分配大块儿连续物理内存的问题经常在 LWN 讨论。虚拟内存，由其性质决定了它总会将页面分散到整个系统；内核长时间运行后，可供分配的页面极少会出现一个挨一个的情况。多年来，内核开发者们处理这个问题的方式就是尽可能地避免对大范围连续内存分配的依赖。内核代码很少会试图分配超过两个的连续物理页面。

近来，关于大范围连续内存分配的需求越来越多。需求之一是超大页面数，尤其是transparent huge pages feature。另一个则是老树开新花了：硬件不能执行分散/收集DMA。任何只能对连续物理内存区域做DMA的设备（缺少I/O内存管理单元）都要求一个物理上连续的缓冲区来协同工作。这个要求通常是相对低端（stupid）的硬件的一个标志；你可以祈求这样的硬件随着时间越来越少。而我们所关注的是获得一定的能力的同时仍然保留着连续DMA要求的那些设备。比如，视频采集引擎，它能够采集完全高清的数据，然后在其上进行一系列的转换，但是它仍然会需要一个连续的缓冲区用来保存结果。高清视频的出现加剧了这个问题，那些物理连续的缓冲区现在比原来需要分配得更多，而且更难被分配了。

大概一年前，LWN 就开始关注解决这个问题的连续内存分配补丁。这个补丁集遵循着在启动时保留一大块内存的神圣而又庄严的传统，而这个的唯一目的就是为了满足大范围的分配需求。多年以来，这个技术一直被“bigphysarea”补丁所使用，或者简单地在启动内核时使用一个mem=的参数，用来留下一段未使用的物理内存。Android pmem driver也是从保留区域中分配大块内存的。这个方法当然有效，将近20年的经验足以证明它。保留内存的不利之处则在于它对其他任何想使用它的东西都是无效的；如果设备没用使用这块内存，它就简单地被闲置起来。这种内存的浪费在内核开发者和用户之间变得越来越不得心。

基于上述及更多的原因，CMA补丁从未被加入进去。尽管问题并没有被解决而且也没有开发者在其上工作，最新版的CMA补丁集看起来十分不同，虽然仍然有些问题需要解决，但是看起来本补丁集有较大的机会加入到主线中。

这个CMA分配器仍然能够同保留内存区域的方式一起工作，但那很明显不是想要的操作模式。相反，新的CMA试图维护当需要时能够创建连续大块内存的内存区域。为了那个目的，CMA依靠“migration type”机制被深度构建进内存管理代码中。

在每一个区段内，成块的页面被标记为被那些可移动的或可回收的页面使用。可移动的页面主要是那些缓存页或者匿名内存页，它们通过页表和page cache radix tree来访问。这些页的内容可以随着页表和树的更新而相应地被移动到其它地方。可回收页，则是在需要时返回给内核；它们像inode cache一样保存数据结构。不可移动页通常是那些内核拥有直接指针的页面，比如，通过kmalloc()申请的内存不能在不破坏任何东西的情况下被移动。

内存管理子系统试图将可活动页面保持在一起。如果要通过移动页面来获得掉一整块空闲内存，一个单独的固定页面就可破坏整个过程。通过将可活动页面分组，内核希望能不用遇到这个障碍就释放更多的页面，内存压缩代码目前就是依靠这些可活动页面才能工作。

CMA通过增加一个新的“CMA”迁移类型来延伸这个机制;它很像”可活动“类型，但有几点不一样。“CMA”类型比较棘手，内核不能改变被标志为CMA的页面的迁移类型。内存分配器不会从CMA区域分配固定页面，对于其他任何用途，只有当没有其他选择的时候才会分配CMA页面。如果一切顺利的话，被标志为CMA用途的内存区域只会包含可活动页面，并且有数量可观的空闲页面。

换句话说，被标志为CMA用途的内存对系统其余地方保持可用，只有一条限制，那就是它只包含可活动页面。当驱动需要一片连续的内存时，CMA分配器就在它的一个特定范围挤出足够的页面创建一个适当大小的连续缓冲区。如果在这里面的页面真正是可活动，分配器就提供驱动所需要的缓冲区。当缓冲区不再需要的时候，内存也可以被用作其他用途。

有人可能好奇为什么需要这样的机制，因为内存压缩机制就已经能够给transparent huge page创建大片物理上连续的块。那样的代码是可用的：我自己的 Linux 系统，在写这篇文章前，有大约25%被分配为大页面。这个问题的答案就是DMA缓冲区相对大页面有一些不同的要求。DMA缓冲区可能更大，例如，transparent huge page几乎在所有架构里都是2MB大小，而DMA缓冲区能有10M或者更多。如果底层的硬件足够“奇怪”的话，可能有必要将DMA缓冲区放在特定内存范围内，而CMA开发者 Marek Szyprowski看起来似乎就有这种“奇怪”硬件的需求。最终，2MB的大页面必须也有2MB的对齐，而对DMA缓冲区的对齐要求就宽松的多。CMA分配器能取得被请求数量的内存而不用过度担心严格的对齐要求。

CMA补丁集为建立内存区域和创建特定范围的“上下文”提供了一个函数集。有简单的cm_alloc()和cm_free()函数来获取和释放缓冲区。虽然如此，但预期设备驱动将不会直接调用CMA，相反，对CMA的意识将被固定在DMA支持函数里。当驱动调用函数如dma_alloc_coherent()时，CMA将自动被使用来满足要求。在大多数情况下，它应该能“正常工作”。

另外一个CMA的关注点是关于特定区域是如何设置的。目前的补丁期望在系统的board file里面做一些特殊的调用。这是一个很ARM式的方法。接下来的目的是去掉board file，这样就会发现其他东西。正如 Arnd Bergmann所指出的那样，将该信息移到设备树也不是一个选择。这其实是一个策略决策。Arnd正努力争取一些能在大部分系统工作的合理默认设置，其它一些少数系统将在后续被加进来。

最终的结果可能是，patch set至少得经过一个迭代才能进入主线。但CMA满足了以前从未遇到过的一个需求。这部分代码有潜在的可能性能够在减小对其余系统的影响的同时，让分配物理地址连续的内存变得更加可靠。看起来它似乎值得拥有。

PHP 的各个实现

挖个坑，备忘

• Zend, 这个就不多说了
• Quercus，原本是 resin 3 的一个特性，现在好似是作为一个独立项目运行... 看论坛上有人已经把它运行在 jetty 上了
• P8，又一个运行在 JVM 上的 PHP 引擎，是一个 IBM 的项目，相比较 Quercus 而言，传说它比较好的支持了 PHP C 扩展。但这个项目的页面严重过时。另外它不是开源的
• Phalanger，PHP on .NET，看起来正在积极的开发中，而且还有商业支持
• PIPP，运行在 Parrot 上的 PHP，这个项目看起来已经死了，而且 Parrot 离被证明还很遥远
• PHP 编译器，这个概念和前面的 Zend/JVM/Parrot 不太一样，着眼于直接编译出可执行代码，脱离 VM
  1. HipHop，地球人都知道
  2. phc
  3. Roadsend的Raven/rphp，基于 llvm

都不容易

暑假过了一个月，达达的心前所无比的野。不爱写作业，想尽办法偷懒

于是最近有那么段时间，几乎每天她妈都和达达发生剧烈冲突

白天我们上班后，奶奶和达达聊天

奶奶：......你说你妈妈容易吗？

达达：那我容易吗？

奶奶：你有什么不容易的

达达：我得让大人高兴

是啊，太不容易了

sohulinux 第六期

1. Webian: 基于 Mozilla 技术的 Web 桌面

2. Android, forking, and control

3. Phantom: 去中心化的匿名网络

4. Throttle buffered WRITE in balance_dirty_pages()

blk-throttle: Throttle buffered WRITE in balance_dirty_pages()

Haraka - a Node.js Mail Server

https://github.com/baudehlo/Haraka#readme

看作者的自述：Haraka is a project started by Matt Sergeant, a 10 year veteran of the email and anti-spam world. Previous projects have been the project leader for SpamAssassin and a hacker on Qpsmtpd, a perl based mail server which is quite similar to Haraka (but not as fast due to perl being slower than Javascript).

貌似不是一个蛋疼的项目... 刚刚发布 0.6.0 版本

Why Use Haraka?

Haraka's primary purpose is to provide you with a much easier to extend mail server than most available SMTP servers out there such as Postfix, Exim or Microsoft Exchange, yet while still running those systems for their excellent ability to deliver mail to users.

postfix 一直没有增加 libevent 的支持，对一个这么活跃的项目，以及这么被广泛使用的服务来说有点异乎寻常。从理论上来说，一个邮件系统的I/O能力是被其磁盘信件队列的I/O能力限制住了，所以网络I/O不追求高并发也可以理解。

但是考虑到垃圾邮件，潜在的DDoS攻击，在 postfix 之前弄一个这玩意确实值得考虑。

以前曾经想过用 twisted 做类似的东东，现在看来又多了一个新选择。

最后要说的是，node/v8 的 gc 确实很蛋疼

Phantom: 去中心化的匿名网络

翻译：曾怀东/朱翊然

互联网上的匿名是一个值得关注的问题，为此，几种不同的解决方案已经实施（如Tor，Freenet）。创建这样的网络是一个蛮有意思的尝试，这种网络也在避免各种互联网活动监控方面大显身手。而在相对自由的国家的人可能会发现它很有用，可以用来避免他们的ISP和政府的监督，在更专制政权下生活的社会活动家可能会发现能利用它获得更多，在某些情况下，甚至是生存或死亡的区别。幻影（ Phantom ）是另一个具有很多有趣熟悉的提供互联网匿名性的机制。

Phantom 协议是由 Magnus Bråding 在 2008 年的 DEFCON16 引入的（幻灯片[PPT]），旨在提供去中心化的匿名性。其思想是不存在会由于关闭或攻击导致Phantom无法使用的中心薄弱点。不像Tor和其他协议，Phantom要求端到端的加密，所以不存在“exit node”的问题。该问题会导致泄密或恶意参与者窃听通讯。另外，Phantom是为了高性能设计的，所以可以支持大数据量的网络传输。

Phantom最有趣的特性之一是它不需要改变现存的internet应用。对于网络浏览器还是其他应用，似乎使用的还是一个标准的 IP 地址和外界通信。事实上，这些地址是由Phantom软件处理的匿名协议（AP）地址。 Phantom做出的假设之一是IP地址能够映射到真实生活身份（这是一个非常有意义的假设），所以它的最主要成果之一就是保证这些信息不会被泄漏。

Internet被用来承载所有的Phantom流量，这些流量是internet的一部分。提供匿名访问服务（例如web server）的服务提供商必须在Phantom网络内部注册。很明显，从去中心化的角度来看，注册是一个问题，但是Phantom使用了分布式哈希表（DHT）来保存信息。现在已经有很多大规模部署的DHT，例如eMule的Kademlia。

DHT被当作“网络数据库”并且包含了两个独立的表。一个表是当前已经连接入 Phantom 的节点的 IP 地址，端口和其它属性，另一个表包含连接入 Phantom 和注册入的节点 AP 地址和属性。显然，为了保证匿名性，这两个表没有直接关联。想要获得一份DHT的拷贝，一个新节点只需要同一个已经存在的节点连接并加入这个分布式数据库就可以。初始可用的IP地址列表可能源于各种途径：网址，邮箱，甚至是纸片。只要列表中有一个的节点存活，新的节点就能够加入。

希望在网络上通信的客户端必须建立自己的退出节点（exit node）。它通过选择网络中一定数量的其他节点建立路由路径，最后一个节点即为退出节点。不像Tor，Phantom中没有已有的退出节点集合，因为在Phantom中任何一个在网络中的系统都可以作为退出节点。还有一点与Tor的区别是，endpoint选择自己的路由路径，而不是由网络来做这些决策。Phantom design white paper [PDF]对产生路由路径的协议进行了详细的说明。路径的每一步都用SSL进行了加密，该文章还描述了生成退出节点的复杂过程的细节。

同样，网络上的任何服务需要为每一个“入口节点”创建一条路由路径。在某些情况下，服务本身并不需要匿名，只是为匿名用户提供访问，这时候入口节点可能是该服务本身。在任何情况下，服务都要利用入口节点的IP地址在DHT注册他们的AP-to-IP的地址映射。对那些希望保持匿名的服务，他们会隐藏在其入口节点的整条路径的后面。

建立exit node和entry node后，节点就依路径创建路由隧道。这些隧道在端点的控制下，而不是网络或者任何的中间节点（包括入口/出口节点）。建立一个连接包括把这两条路由隧道连接在一起，以及连接客户的出口节点和服务的入口节点。隧道连接是双向的，使用了防备中间人窃听的加密技术

该系统的重要特征之一是，节点不知道他们对话的对象是端点或者仅仅是路由路径上另外一个节点。路由路径可以是无限长，甚至可以根据需要再次链接起来去提供进一步的隔离。

虽然整个计划看起来恶魔般的复杂，它已经作为Johannes Schlumberger的一部分硕士学位的工作实现了。也许令人惊讶，性能被描绘为还不错的：“在多跳路的Phantom路由隧道上最大达到100Mb/s的数据传输速度，因此加密的开销似乎并不太重要”。该代码可以在Hacktiyismo 增强源软件许可协议（HESSLA）下使用，这似乎是带有一些额外“政治”目标的GPL-inspired 许可证。根据自述，用一个tun的虚拟网络设备实施，而且可能需要相当复杂的设置。

总体而言，Phantom看起来很有趣。像Tor以及其他的技术，为了真正的使用，需要相当多数量的节点参与进来。Tor的一个最大的障碍在于出口节点因为它们发出的通信习惯获得指责。这些通信不能进一步的追踪回出口节点（至少希望如此），任何犯罪的或者恶意的通信是同任何跑在Tor节点上的用户隔离开的。由于在Phantom上的服务支持匿名访问，这样问题可能比较少。这也可能导致采用Phantom的可能性较小。

虽然电子前沿基金会最近一直在推动Tor的使用，广泛的使用Phantom（或者任何其他的匿名网络协议）还是有点困难的。有些方案显然是必要的，但是目前为止，后勤和法律的障碍似乎是许多人无法克服的。不幸的是，匿名网络可能会陷入“直到太晚的时候才开始成立”的困境。但是，很高兴看到人们仍在思考并且一直在为这个问题工作。

Android, forking, and control

翻译：马少兵/刘晓佳/李潇

关于 Android 和 Linux 主线开发的关系已经被谈论很久了。在日本的 LinuxCon，James Bottomley 又就此阐述了很多观点。他说，从两个项目之间缺乏联系和交流可以学到很多教训，如果社区能关注这些往事，未来我们应该能做得更好

• Forking the kernel

• 重写了 C 库和工具链

• 开发了一个 Java 应用框架（JVM定制）

• 项目启动的时候，对 GPL 极为排斥

换句话说，Android 是一个不同社区合作的典型代表。它们做了无数社区觉得不该做的事情，但是最后成功。尽管我们觉得 Android 的开发团队需要有所改变，但它的成功也说明，社区也需要有所改变。也许社区需要重新权衡代码质量以及市场成功，社区是否需要更加面向商业一些？？

一个最大的争论就是 forking，不仅仅是 kernel，Android 从零编写了整套用户空间，社区对此特别愤怒。但我们得理解这个事情的历史过程。最开始 Android 是期望它的变更能被主线采纳的，但在开始实现系统的过程中，时间压力很大，不得不尽早往前赶进度。我们都知道关于内核社区的补丁复查和接纳过程有很多议论，总之Google 无法等待社区接受后再发行它的 Android。但也许，除了 forking 内核外我们还能有其它选择

“难道内核分支是一种错误吗？”，在某种意义上来说，James说，那不是错误：毕竟有 GPL 担保。分支有时候是必须的，如果android系统不能被应用，原来那种正确也是无意义的。在此特殊情况下，如果不采用分支，android系统的商业的开发与应用将会处于一个艰难的时刻,很难实现其目标（关于电源管理以及其他）。最终将会导致android代码被推迟，而这一切，会使目前市场缺少很多产品，或许因为错过市场时机项目就悲剧了。分支，换句话来说，也是一个好的事情——相比较于内核社区的固定流程，不同的团队可以做更多的事情

James问到，分支化等同于分裂化吗？这是个很重要的问题：上世纪九十年代分裂化几乎杀死了Unix的市场。他声称失败的分支化并不会分裂Linux社团；相反，他们只是简简单单的消失而已。那些合并后回到父工程的分支化并不代表着分裂化；他们将代码和开发者带回了原始的工程。真正有害的分支化，是那些取得成功并带走了一部分社团的分支，它们不会再回到父工程了。从这个角度讲，很有必要让社团帮助分支合并回来。

除了分支化了内核，Android的开发者，曾经认为GPL对于商业化并无益处。该工程最初避免任何GPL-licenced的代码；本来计划是写一个全新的内核。最后，由于某些原因，采用了GPL-licenced的Linux内核；同时还保留一些其他GPL-licenced的组件。所以，James说，我们应该谢谢Andy Rubin – 是他最初讨厌从GPL来的代码 – 最后决定性的证明了一款含有GPL-licensed代码的手机在市场上是可以成功的。结果就是下游销售商不用关心他们设备里代码的许可证；只需要关注清晰一致即可。

关于Android特别应用框架呢？James说基于Java的应用程序框架是Android系统最大的创新；它将平台细节抽离出来，使得应用层尽可能地远离了内核。该框架限制了应用程序可用的API，对应用所能做的以更强的控制。给定该结构后，貌似重写C库是一件完全没必要的事情；在该框架下没有人会尝试直接使用C库的。

所以，Android并没有做错一切。但是还是犯了一些错误：从James角度看，最大的错误就在于一开始它缺乏支持SyncML的日历应用。这使得Android很难吸引商业人士。黑莓成功的关键之处就是它优秀的日历。摩托罗拉看到了该问题，并为Droid系列手机实现了它自己专有的SyncML日历系统；这实际上使得事情更糟了，因为商业人士购买Android手机的出发点就变成了它能够支持日历系统。如果除了Droid之外别无他选，就会非常令人失望，最终转投iPhone平台。直到一年后，2.1版本，Android才支持SyncML，也是从零开始重头编写。

Android的另外一个问题是它的“walled garden”开发手段。Android本来是个开源工程，但是谷歌却对基本的发行维持总控制；在谷歌把代码扔出墙外前没有别人可以看到代码。没有一个变化是来自第三方提供的，所以没有社团来维护该代码，没有共享的创新。举个例子，如果愿意接受来自外界的帮助的话也许早就解决了日历的问题了。谷歌对代码的总控制是因为需要给工程以市场焦点。这是达到市场统治的先决条件，但是对社团来说并无益处，并且迫使谷歌重复了许多已有的创新。

另一个大问题是来自甲骨文的起诉。该控告基于Android对Java语言的重写，这完全是因为 Android 害怕GPL所至。要是Android建立在甲骨文的GPL-licensed的Java代码基础上，应该不会有法律问题；按照GPL暗示的专利许可，Google本该被保护。如果甲骨文赢得这场官司，重写Java将意味着在许可证逃避方面极其昂贵的实践。令人悲痛的是该license是完全无关紧要的：Java runtime API 将应用同 GPL 隔离

学习到的教训

我们能从这些里面学到什么？James重申，只有最终合并回去，创建分支才是一件好事。虽然做出了大量的努力，但Android分支还未合并回去。也不清楚Android开发者是否已经开始实施内核社区提出的解决方案。他说，也说我们需要想出一种方法让合并更容易。尤其是在创建的分支壮大的情况下，社区应该有一种更好的方法来处理当前这个有可能在审查中陷入困境的过程。

创建分支的项目还要考虑一下这些过程。子分支开发团队容易产生“非我发明”的心态（指反感或拒绝使用不是自己发明的技术），这反而会导致他们不愿意展示自己的最终代码。把自己都知道贴出来就要被社区严厉批评的代码贴出来一点都不有趣。子分支发展越久，这种状况越糟糕；修正基础的设计错误（正如社区眼里wakelocks的作用）就会越困难。要防止这个问题就要求分支团队更加包容，更频繁的贴出他们的代码，并寻求社区的建议—即使他们并不打算接受这些建议。打开围墙并让双方交流各自的想法是很重要的。

James谈到了“授权恐惧”，说GPL是我们特别感到FUD的地方。我们在社区里的一些关于“授权”的讨论在行业界人士看来就像是一个令人害怕的问题。而社区里关于这个话题的讨论不像那样激烈，这反而大有好处。对GPL的恐惧是由外界的兴趣驱动的，但我们趋向于让事情简单。社区应当更加前瞻性的去缓和这种恐惧；将Android看作在GPL授权下如何运转的一个范例，这是缓和恐惧的一种可能性。Linux基金会做过一些这样的工作，但是James觉得社区该出手帮助。他说，GPL比起那些最具商业性的授权，遵守起来容易得多，这是我们需要更加明白的一点。

我们应该设计更加“bright line”的系统，这会让GPL问题变得更加明确。内核用户空间ABI就是这样的一个系统；开发者知道用户空间代码被认为不会被内核的 GPL 所污染。让这个界限更容易的理解，会有助于减少对GPL的恐惧。

社区应该在提倡和发展多样性，鼓励创建分支（这会创造更多显著地成就）并帮助他们合并回去。James说，如今内核最多能得一个“C”的成绩。我们只从看起来跟我们相似的人那里接受代码，Android的合并尝试比原本想象的更加痛苦。

企业们应当靠获得社区拥护而不是绝对所有权来控制代码。Linus Torvalds就是一个例子；他有许多控制权，但那是因为社区信任他能做正确的决定。一般来说，如果社区信任你，它就会交出大量的控制权；那就是为什么仁慈的独裁者模型如此平常的原因了。另一方面，那些试图通过设置开发壁垒或者通过要求贡献者转让版权来声明控制权的企业们与社区相处得更加困难。

James说，总之，Android对任何参与进来的人而言都是一个惨败；我们都需要想清楚怎么去做的更好。我们需要找出更好的鼓励和管理分支并减轻授权恐惧的方法。创建分支的项目从一开始就应该仔细考虑合并回去的事情。这样，那些商业成功的项目（如Android）能同样是社区的成功