软件之间的兼容性问题分析

问题

     +-------+   +------+
     |  app  |   | app  |
     +-------+   +------+
              \ /
               X
              / \
             /   \
     +-------+   +------+
     |  lib  |   | lib  |
     +-------+   +------+
              \  /
               \/
               /\
              /  \
     +--------+  +--------+
     | kernel |  | kernel |
     +--------+  +--------+

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
的标记，提示用户相关接口将会在未来弃用。

[1] https://wangzhou.github.io/Linux驱动软硬件兼容问题的考虑/