简介：本文是[1]的扩展，分析不同软件实体之间的兼容性问题，大致包括内核和用户态
之间的兼容性和用户态不同层次软件实体之间的兼容性。

问题

  1.          +-------+   +------+
  2.          |  app  |   | app  |
  3.          +-------+   +------+
  4.                   \ /
  5.                    X
  6.                   / \
  7.                  /   \
  8.          +-------+   +------+
  9.          |  lib  |   | lib  |
  10.          +-------+   +------+
  11.                   \  /
  12.                    \/
  13.                    /\
  14.                   /  \
  15.          +--------+  +--------+
  16.          | kernel |  | kernel |
  17.          +--------+  +--------+
  19.     old ------------------------> new

如上图，我们需要解决的是新老软件版本之间可以兼容使用的问题。

kernel和user space

内核和用户态接口包括，系统调用、设备文件、sysfs/proc等。这些接口可以看成是独立
的功能。所以，在用户态使用一个如上的接口时，可以先检测是否有这样的接口。对于
设备文件和sysfs/proc很容易判断一个文件是否存在，对于系统调用如果一个接口底层
驱动没有支持，用户态应该得到不支持的错误码，这需要内核驱动做必要的异常处理并
返回错误码。

我们考虑lib和kernel之间的新老兼容问题。对于老的内核，新的lib，lib中的代码依赖
老的kernel接口编程，并先要检测kernel的接口是否可以使用，之所有要检测kernel接口
是否可以使用，是为了防止随后kernel版本里删除之前的接口，造成lib的break; 内核
升级但是lib还是老的情况，kernel里新增的接口lib里使用不到是正常现象，kernel里
删除的接口(一般不会发生)，lib在之前使用的时候已经先判断是否支持，考虑的逻辑已经
存在。

user space lib和app

lib和APP之间的接口一般是函数接口，比较难做成特性独立定义。那么在lib发展的过程
中，删除一个特性，必然造成接口的不兼容。所以，要实现新旧库和APP相互兼容，我们
可以lib库里的特性持续增加，并在增加特性的时候做好库版本的定义升级。APP在编程的
时候根据lib版本决定是否可以使用某一个特性。

持续增加lib中的接口必然造成库的膨胀，可以给将来不计划使用的接口加上deprecation
的标记，提示用户相关接口将会在未来弃用。
————————————————
版权声明：本文为CSDN博主「sherlock-wang」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/scarecrow_byr/article/details/112544667