API 与 ABI

（本文亦是《C语言编程艺术》中的一部分，所以请勿用于商业用途。）

一些程序员居然对API和ABI这两个概念都不清楚，我感到有些惊讶。这里以 Linux 内核为例简单解释一下。

API，顾名思义，是编程的接口，换句话说也就是你编写“应用程序”时候调用的函数之类的东西。对于内核来说，它的“应用程序”有两种：一种是在它之上的，用户空间的真正的应用程序，内核给它们提供的是系统调用这种接口，比如 read(2)，write(2)；另一种就是内核模块了，它们和内核处于同一层，内核给它们提供的是导出的内核函数，比如 kmalloc()，printk()。这些接口都是你可以在编写程序的时候直接看到的，可以直接拿来用的。

而 ABI 是另一种形式的接口，二进制接口。除非你直接使用汇编语言，这种接口一般是不能直接拿来用的。比如，内核系统调用用哪些寄存器或者干脆用堆栈来传递参数，返回值又是通过哪个寄存器传递回去，内核里面定义的某个结构体的某个字段偏移是多少等等，这些都是二进制层面上的接口。这些接口是直接给编译好的二进制用的。换句话说，如果 ABI 保持稳定的话，你在之前版本上编译好的二进制应用程序、内核模块，完全可以无须重新编译直接在新版本上运行。另一种比较特殊的 ABI 是像 /proc，/sys 目录下面导出的文件，它们虽然不是直接的二进制形式，但也会影响编译出来的二进制，如果它里面使用到它们的话，因此这些“接口”也是一种 ABI。

你平时看到的什么 POSIX 标准啊，C99 标准啊，都是对 API 的规定。而规定 ABI 的标准就不多，而且也没那么强势，Linux 上面的 ABI 标准似乎只有 Linux Foundation 提供的一些标准。

好了，从上面我们可以看出，其实保持一个稳定的 ABI 要比保持稳定的 API 要难得多。比如，在内核中 int register_netdevice(struct net_device *dev) 这个内核函数原型基本上是不会变的，所以保持这个 API 稳定是很简单的，但它的 ABI 就未必了，就算是这个函数定义本身没变，即 API 没变，而 struct net_device 的定义变了，里面多了或者少了某一个字段，它的 ABI 就变了，你之前编译好的二进制模块就很可能会出错了，必须重新编译才行。

你可能会感到意外，上游的 Linux 内核其实不光不保持稳定的 ABI，它就连稳定的 API 都不会保持！而且还牛逼哄哄地写了一个文档，叫 stable_api_nonsense.txt。这么做的道理是，内核一直在向前推进，而且速度很快，内核开发者们并不想因为 API 的限制而阻碍前进的脚步！毕竟我们不想成为下一个 Windows！:-)

所以，你的驱动在不同版本的内核上不经修改直接运行那几乎是不太可能的，就算是你允许重新编译也未必就能不经修改编译成功。即使在同一个大版本的不同发行版上也可能不行。

那你应该怎么办？最好的办法莫过于把你的驱动贡献到社区，汇入内核源代码树中，这样一旦内核的 API 有改动，改动这个 API 的人就有义务替你修改你的驱动的代码，你只需要 review 一下（或者这个也会有人帮你），也省去你不少时间，何乐而不为呢？另一种办法就是基于某个提供稳定 ABI 的内核，比如红帽的 RHEL （认为这是广告的人请使用 CentOS，谢谢！），红帽的企业版内核保证有稳定的 ABI，只要你没有跨大的版本，因为我们的源代码里会检测 ABI 的变化，为此我们实在付出了不少努力。

当然了，如何检查 ABI 变化那就是另一个有意思的话题了，以后有机会慢慢说这个问题。