LWN：magic 消失了！

关注了就能看到更多这么棒的文章哦～

Losing the magic

By Jonathan Corbet
December 5, 2022
DeepL assisted translation
https://lwn.net/Articles/915163/

kernel 项目现在已经有三十多年的历史了。这期间不断有一些开发实践（development practice）出现和消失。曾几何时，人们认为用 "magic number" 来区分内核里的数据结构是有助于检测到问题以及调试问题的一个好方法。不过，多年来，magic number 的使用逐渐减少；Ahelenia Ziemiańska 的这个 patch set 可能表明，magic number 的统治已经走到了尽头。

magic number 只是一个具体的常数，放置在一个 struct 中，通常是作为第一个成员变量，用来确定这个结构是哪种类型。在采用了这种方式标记某个 structure 的时候，内核内的 debug 相关代码可以检查这个 magic number，如果看到不是预期的值，就会提出警告，从而检测到例如 type confusion 或者 data corruption 等问题。这些数字也可以放在十六进制的 data dump 中（例如，dump 一下 stack 内容），就可以识别出已知的数据结构。

在内核中使用 magic number 这个做法，似乎起源于文件系统的相关代码，最初是用来识别（和验证）磁盘镜像中的 superblock 的。甚至在 0.10 版本的内核中就包括了对 SUPER_MAGIC（0x137f）的 test 代码，从而验证这个 boot disk 的确是 Minix 文件系统。其他文件系统是后来才逐步出现的，从 "first extended"（ext）文件系统开始，在 1992 年 7 月的 0.96c 版本中，它使用了 0x137d 作为 EXT_SUPER_MAGIC 值。

在 0.99 版本（1992 年 12 月发布）中，网络子系统中用来保存数据包的 sk_buff 结构（现在仍在用它）比现在的 size 要小，但也确实有一个 magic 字段来识别数据包期望应该放到那个队列里。在 1993 年中期，0.99.11 版本中增加了新版的 kmalloc()实现，在其周围也放置了 magic number 用来帮助调试。顺便说一下，那个版本也是首次尝试使用 C++ 来构建内核的版本，不过只持续了几个月，到 0.99.13 就结束了。

在那之后，在内核中使用 magic number 的情况慢慢增多。1994 年 5 月发布的 1.1.13 版本在顶层目录中增加了一个名为 MAGIC 的文件，用来跟踪各个 magic number 的使用情况；它当时列出了八个。顺便说一下，这个文件几乎是内核中除了最基本的 installation 信息之外的第一个作为文档的文件；内核直到 1995 年的 1.3.22 版本中才拥有了一个 documentation 目录。在这个新文件中，Ted Ts'o 写道：

用魔法数字保护内核数据结构是一个 非常 好的主意。这可以让你在运行时检查：(a) 某个结构是否被破坏了，或者 (b) 你是不是把错误的结构传给了错误的实现函数。这一点特别有用，尤其（Ted 错误地拼成了 particlarly）是你通过 void * 类型来把传递某个结构指针时。例如 tty 代码就经常这样做，来回传递一些不同驱动程序和不同的 line discipline 都不一样的 structure。

该文档中，要求开发人员在今后添加内核代码时都遵循这一做法。(如果有人有兴趣知道的话："particularly" 这个错别字一直到 1994 年 8 月的 1.1.42 版本才被修复，所以没能一直持续到今天）。

在 1.3.99 版本中，MAGIC 被移到了 Documentation/magic-number.txt 中，这也许是在后续很快到来的 2.0 版本之前进行的全面清理工作的一部分。至少有些开发者明显地接受了 Ts'o 的建议；此时，该文件中有 21 项。2.2.0 版本（1999 年 1 月）有 51 项。magic number 似乎是一个已经被接受了的内核开发惯例（practice）。

2.4.0 版本是在差不多两年后发布的。2.4 版本中的 magic-number.txt，除了一个小的改动之外，与 2.2 版本完全相同。其中没有增加新的 magic number。这并不一定代表我们的开发惯例有了什么变化，实际上是出于人们永远都是不及时更新文档的这个惯例。在 2.5 开发系列中花了一些功夫来更新文件， 2.6.0 版本中甚至包含了 100 个 magic number。但在 2.6.x 系列的其余部分，唯一的变动就是小调整，以及删除了几个过时项；此时 Documentation/magic-number.txt 开始缩小了。

事实上，在 Git 开发时代中，完全没有对该文件进行过任何补充了。2016 年，该文件被转换为 RST 格式，并被移动到新撰写的 development-process 说明中。直到今年早些时候，该文件开始缩减；6.1 版本的 Documentation/process/magic-number.rst 已经减少到了 14 个条目。那这些 magic number 到哪里去了呢？

这个变化是 Ziemiańska 工作的成果，他的目的是完全删除这个文件；目前的 patch set 中将其描述为 "往好里说，是一个没有太多用的历史遗迹，往坏说的话，就是许多带有误导性的杂乱内容"。在这组 patch 中，Ziemiańska 慢条斯理地删除了最后剩余的那些项，还经常会删除相关的 structure 字段以及代码中的 magic-number 的检查代码，最终让这个文件变成了空文件；该系列的最后一个 patch 就只是把这个文件删除掉了。这个动作肯定是不会漏掉的。

不确定是什么时候开发社区集体决定不再采用 magic number 的；它纯粹就是逐渐消失了。这种变化背后可能有几个原因。多年来，内核社区一直试图使用 type-safe 的接口，而不是到处传递 void 类型的指针，这样可以降低把错误的 structure 类型传递到函数中的可能性降低。开发人员越来越少需要盯着十六进制数据 dump 来分析了，他们现在更喜欢用结构化输出（more structured output）、tracepoint、以及交互式调试器（interactive debugger）来作为追踪问题的主要方法了。内核的内存分配器的一些 debug 机制也意味着许多种内存被破坏的问题将被直接捕获到。magic number 已经不再像以前那样有帮助了。

Magic number 其实仍然是有应用场景的。例如，它们仍然可以帮助文件系统代码来确保它正在处理正确类型的文件系统镜像文件。哪怕是在这种情况下，其实对磁盘上的数据结构使用校验和检查可以对许多类型的问题提供更好的保护。但是，在大多数情况下，内核开发已经失去了它曾经拥有的一些 magic；就像人们经常碰到的情况一样，很多东西都是在没有人注意的时候就悄悄离开了。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～