第二起跑线（三）——评论：Yes We Can
这次“富士康”事件的主角，看似是主板，实际上，是 BIOS。更准确一点说，应该是 BIOS 所保存的 ACPI 代码中的 DSDT 表部分。或许看了这个专题前两部分热闹，你仍然不清楚什么是 ACPI 标准，什么是 DSDT，以及它们为什么重要，那么这里我将尽我所能做点解释。
ACPI，全称 Advanced Configuration and Power Interface，是从 APM（Advanced Power Management）进化而来的一整套涉及电源管理的 BIOS 代码。现代绝大多数电脑硬件的常见功能如 CPU 频率自动调节、挂起/休眠、CPU 风扇的智能调速等等，无不仰仗 ACPI。
但是，并非所有的硬件都支持 ACPI（ACPI 1.0b 颁布与 1999 年），也并非所有的操作系统支持 ACPI，况且从 1999 年的 1.0b 到目前的 3.0b 到正在开发当中的 4.0，ACPI 自身也在不断发展完善之中。为了取得更好的兼容性以及用户体验（其实是对用户透明，你感觉不到它的存在才证明它的成功，这点 GFW 仍需努力），ACPI 想了这样一个办法（OS 指操作系统，后略）：
注意表格当中字体加粗的部分，问题就出在这里。这也是 ACPI 中为什么要有 DSDT 的原因。
DSDT，全称 Differentiated System Description Table，启动时 OS 通知 ACPI 自己支持 ACPI，然后可以从这里获得系统相应的 ACPI 实现和配置的信息（ACPI 有很多版本，不是吗）。
我相信如果 OS 通知给 ACPI 的是自己支持的 ACPI 标准版本，那么事情将简单许多——事实是，OS 传递给 ACPI 的是一个标识自己的字符串。比如
如果你反编译一下你的 DSDT（在 Linux 下，这么做真的很容易，这要感谢英特尔），你就能看到那个庞大的巨丑无比的 if-else 嵌套块——以上字符串就来自于我正在写这篇文章的富士通笔记本，不同的 BIOS 会包含更多不同的字符串，它们全加起来比 ACPI 版本的数量还要多。不用奇怪 ACPI 标准为什么会容忍 OS 相关性这么强的字符串，看一下起草 ACPI 标准的成员名单你就会明白：惠普、英特尔、微软、Phoenix（就这一家是做 BIOS 的）和东芝。
但更加不幸的是，很多硬件制造商根本没能力提供全功能的 DSDT 表，甚至 ACPI 成员厂商也不例外（稍后再述）。
于是，生存在非微软世界的 PC 开发人员和用户就一直在和恶劣的 BIOS 做着不懈的斗争。这次“富士康事件”，仅仅是自 Linux 2.6 内核不断成熟、可用性空前进步加上 Ubuntu 大力推广扩大了用户群之后的一次影响范围稍大的冲突而已。看看那么丰富的 DIY 修改版 DSDT 库（是的，Linux 支持用一个自己修改过的 DSDT 文件来代替内置在 BIOS 里的那个），你就能想象 Linuxer 们自己动手、丰衣足食的传统有多么悠久。今天的 Linux 内核更是宽容，它可以告诉 ACPI 自己是任何版本的 Windows 以求正常工作——除非 DSDT 给 Linux 还刻意准备了一份信息。而这次事件中，富士康恰恰就是这么做的，而且那份信息恰恰有问题。
或许你并不关心 Linux。但是我要提醒你的是，同样的手段可以用在不止 Linux 的身上。记得 HP 6520S 近半年难以安装 WindowsXP 的事件么？回忆一下 Halo 3 Vista Only，DirectX 10 Vista Only，我向来不惮以最坏的恶意揣测微软——你以为惠普这个不大不小的“疏漏”是微软赞助下的一次强推 Vista 的尝试？嗯，我还没这么说。
标准，本来是大家做事的准则。标准的制定当然不能缺少微软（否则这对微软也不公平不是）。但是我们都不希望看到标准被污染，也都清楚微软污染标准的能力（请回忆 OOXML 事件）。利用标准的控制权，微软可以合法的将竞争对手推到第二起跑线上。因此，我很赞赏 Ryan 的做法，也由衷敬佩美国公平交易委员会的威慑力（呃，写到这里总是自我迫害般的妄想如果这事发生在国内会如何如何）。我们应该好好学习 Ryan。因为只有给第二起跑线上的人们一个公平的机会，我们的切身利益才有保证——该出手时就出手，套用奥巴马的口号——“Yes We Can”。
ACPI，全称 Advanced Configuration and Power Interface，是从 APM（Advanced Power Management）进化而来的一整套涉及电源管理的 BIOS 代码。现代绝大多数电脑硬件的常见功能如 CPU 频率自动调节、挂起/休眠、CPU 风扇的智能调速等等，无不仰仗 ACPI。
但是，并非所有的硬件都支持 ACPI（ACPI 1.0b 颁布与 1999 年），也并非所有的操作系统支持 ACPI，况且从 1999 年的 1.0b 到目前的 3.0b 到正在开发当中的 4.0，ACPI 自身也在不断发展完善之中。为了取得更好的兼容性以及用户体验（其实是对用户透明，你感觉不到它的存在才证明它的成功，这点 GFW 仍需努力），ACPI 想了这样一个办法（OS 指操作系统，后略）：
| 硬件\OS | 传统 OS | 支持 ACPI 的 OS |
| 传统硬件 | 传统硬件配传统 OS，没什么问题 | 如果 OS 缺乏对传统硬件接口的支持，ACPI 以硬件方式接管全部旧有功能 |
| 支持 ACPI 同时保留传统接口的硬件 | 在传统 OS 下，就跟使用传统硬件一样 | 启动时 OS 告知硬件从传统接口切换到 ACPI，之后即为完整的 ACPI 支持 |
| 仅支持 ACPI 的硬件 | 电源管理功能失效 | 完整的 ACPI 支持 |
注意表格当中字体加粗的部分，问题就出在这里。这也是 ACPI 中为什么要有 DSDT 的原因。
DSDT，全称 Differentiated System Description Table，启动时 OS 通知 ACPI 自己支持 ACPI，然后可以从这里获得系统相应的 ACPI 实现和配置的信息（ACPI 有很多版本，不是吗）。
我相信如果 OS 通知给 ACPI 的是自己支持的 ACPI 标准版本，那么事情将简单许多——事实是，OS 传递给 ACPI 的是一个标识自己的字符串。比如
Windows 2006
Windows 2001.1
Windows 2001 SP1
Windows 2001
Microsoft Windows
Microsoft WindowsME: Millennium Edition
Microsoft Windows NT
如果你反编译一下你的 DSDT（在 Linux 下，这么做真的很容易，这要感谢英特尔），你就能看到那个庞大的巨丑无比的 if-else 嵌套块——以上字符串就来自于我正在写这篇文章的富士通笔记本，不同的 BIOS 会包含更多不同的字符串，它们全加起来比 ACPI 版本的数量还要多。不用奇怪 ACPI 标准为什么会容忍 OS 相关性这么强的字符串，看一下起草 ACPI 标准的成员名单你就会明白：惠普、英特尔、微软、Phoenix（就这一家是做 BIOS 的）和东芝。
但更加不幸的是，很多硬件制造商根本没能力提供全功能的 DSDT 表，甚至 ACPI 成员厂商也不例外（稍后再述）。
于是，生存在非微软世界的 PC 开发人员和用户就一直在和恶劣的 BIOS 做着不懈的斗争。这次“富士康事件”，仅仅是自 Linux 2.6 内核不断成熟、可用性空前进步加上 Ubuntu 大力推广扩大了用户群之后的一次影响范围稍大的冲突而已。看看那么丰富的 DIY 修改版 DSDT 库（是的，Linux 支持用一个自己修改过的 DSDT 文件来代替内置在 BIOS 里的那个），你就能想象 Linuxer 们自己动手、丰衣足食的传统有多么悠久。今天的 Linux 内核更是宽容，它可以告诉 ACPI 自己是任何版本的 Windows 以求正常工作——除非 DSDT 给 Linux 还刻意准备了一份信息。而这次事件中，富士康恰恰就是这么做的，而且那份信息恰恰有问题。
或许你并不关心 Linux。但是我要提醒你的是，同样的手段可以用在不止 Linux 的身上。记得 HP 6520S 近半年难以安装 WindowsXP 的事件么？回忆一下 Halo 3 Vista Only，DirectX 10 Vista Only，我向来不惮以最坏的恶意揣测微软——你以为惠普这个不大不小的“疏漏”是微软赞助下的一次强推 Vista 的尝试？嗯，我还没这么说。
标准，本来是大家做事的准则。标准的制定当然不能缺少微软（否则这对微软也不公平不是）。但是我们都不希望看到标准被污染，也都清楚微软污染标准的能力（请回忆 OOXML 事件）。利用标准的控制权，微软可以合法的将竞争对手推到第二起跑线上。因此，我很赞赏 Ryan 的做法，也由衷敬佩美国公平交易委员会的威慑力（呃，写到这里总是自我迫害般的妄想如果这事发生在国内会如何如何）。我们应该好好学习 Ryan。因为只有给第二起跑线上的人们一个公平的机会，我们的切身利益才有保证——该出手时就出手，套用奥巴马的口号——“Yes We Can”。
评论