FreeBSD

总算是发公告了，可以说具体的事情了。

FreeBSD昨天发布了2项安全公告和1项Errata Notice：SA-09:13.pipe、SA-09:14.devfs和EN-09:05.null。两个安全公告修正的是同一类问题，也就是我们常说的多线程程序中的竞态条件（Race Condition）；EN-09:05.null则是增加了一个使这类问题不再那么容易被利用达到特权提升目的的功能，但默认并不启用。

先把想法记下来。

• 提供一种描述语言，将应用层协议描述成DFA；
• 一个generator将DFA转换为代码；
• 用户态程序通过某种接口来向kernel请求已经协商好的该种协议的socket并由kernel直接填写一部分数据结构；
• 应用程序对socket的第一个回应有时间限制—-如果一段时间之内不回应，则系统将该socket交给下一个监听进程。

解决的问题：

FreeBSD先前的vesa framebuffer驱动有个问题，就是滚屏的时候会比较慢。jkim大长辈于是改了一行代码。

好吧，我承认我之前一直以为是console驱动想要锁&Giant的问题。其实真正的原因是默认的pmap_mapdev并不做写合并，所以应该呼叫更低阶的pmap_mapdev_attr并传入PAT_WRITE_COMBINING参数。

FreeBSD从8.0开始支持从ZFS引导系统，因此，可以使用ZFS的快照功能来实现快速部署。

新机器使用LiveFS启动，Fix it，CDROM。

FreeBSD支持以DSR（Direct Server Return，即服务器直接将流量通过路由器返回，而不经过负载平衡设备；俗称"单臂模式"）模式提供服务。为了改善服务的可用性，可以使用这种方法来配置服务器。这种方法非常适合于大并发、大流量的环境。

前一段时间commit了来自XFree86 -> NetBSD -> OpenBSD的x86emu，这是一个大约9千行C代码的x86实模式CPU模拟器。

由于 amd64/EM64T “long mode” 不支持先前 x86 保护模式中的 “vm86” 扩展（虚拟实模式环境），因此，这个模拟器使得 FreeBSD 能够在 amd64（EM64T） 平台上支持 vesa、dpms 等功能了。

今天 -HEAD 被命名为 FreeBSD 9.0-CURRENT 了（对应的 __FreeBSDversion 是 900000）。从流程上说，这么做的意思是 -HEAD 终于准备解冻进入 slush 状态了（另外，8.0-BETA3应该很快会发布了），基本上之前的一些障碍也都扫清了，目前看来，8.0-RELEASE应该只推后两周左右。。

下周一的8.0-BETA2会包含这个。CAM/AHCI是按照CAM框架重写的AHCI驱动（之前是ata(4)），提供了包括NCQ等硬件特性的支持，并改善了对SATA光驱的支持。与OpenBSD的实现不同，FreeBSD实现通过扩展CAM框架使其直接对ATA设备提供支持。

如题。

不过这一次因为-CURRENT code slush的缘故，应该不会在 8.0-CURRENT 里面引入了（Ed在svn里面建立了另一个branch来做）。我想从各方面考虑，9.0-RELEASE里面正式砍掉gcc那一套东西应该不会是很困难的事情。传统上 FreeBSD 的代码用到了很多gcc的扩展，因此可能还需要一段时间。

First of all, thanks goes to all people who has helped me on this project, especially Pav (portmgr@) who gave it a twist on pointyhat.

It seems that this has taken me almost a month and 20 commits to get into the tree, after the code is ready. At the beginning, the changeset was ~200KB, and I believe it’s not good to just go ahead and commit it in one time, since it makes reviewing hard. Instead, I manually split it into smaller, functional related chunks, and commit it part-by-part.