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

DVB, header files, and user-space regressions

By Jake Edge
August 25, 2021
DeepL assisted translation
https://lwn.net/Articles/867275/

最近 Linux 5.14 版本中 media 子系统出现了一次比较奇怪的质量回退（regression）。内核的用户空间二进制接口（ABI）并没有发生变化，而一般来说要 revert 某个 patch 的话通常都是因为这类原因，但这次的时间报告仍然导致了 patch revert。因为这次的代码改动确实导致了用户空间应用程序的编译问题，因为它把一些头文件移到了 staging/ 目录之下，这是清理已经废弃（deprecated）的（虽然其实仍然可用的）数字视频广播（DVB）设备的驱动程序引出的改动。这里有几个不同的问题纠缠在一起，但用户空间 API（而不是 ABI）的质量回退是一个新的问题。

Soeren Moch 在 8 月 11 日的一篇详尽的邮件中报告了这个 regression 问题。该邮件的部分内容是对 Linus Torvalds 说的，要求 revert 掉 media 子系统维护者 Mauro Carvalho Chehab 提交的三个 patch。这些 patch 将 av7110 驱动移到了 staging 位置，并将一些文档和头文件也移动了过去。但这破坏了视频录像机（VDR）应用程序中一些部分的编译工作，而 Moch 指出这个应用程序在多个 Linux 发行版中都缺省提供了。

他引用了一个由 VDR 社区的另一个成员提出的 Red Hat bug，作为证据。VDR 使用了 uapi/linux/dvb 目录下的头文件，当这些文件被移动时，VDR 在即将到来的 Fedora 35 使用的内核上就无法完成编译了。除此之外，Moch 不同意将这种 "长期存在并能正常工作的 av7110 驱动程序 " 移到 staging/。

这封邮件的大部分内容是发给 Chehab 的，认为不应该将现有 DVB API 改为 deprecated [更新：正如 LWN 评论中指出的，这是 av7110 中实现的 "全功能 "DVB API，只是被 VDR 所使用到]、删除 av7110 支持、以及抱怨 Chehab 不愿意合并另一个同样实现了该 API 的驱动程序。Moch 说，有一些现在在用的设备和现成的 DVB stream 都是在通过这些驱动程序来访问的。他对 Chehab 在移动 av7110 的 patch 带有的 commit message 有些不同看法：

你的提交信息 "解码器只支持 MPEG2，与几个现代 DVB 流不兼容 " 往好里说也得算是有误导性的。德国最流行的卫星电视供应商（Astra）仍然在用 MPEG-2 编码传输大多数有趣的节目，所以这应该算是在活跃使用中的，没有理由让这块卡退休。

但 Chehab 的看法不同：av7110 硬件在 15 年前就已经停止生产了，而驱动所实现的 DVB API 对今天的硬件没有用：

被删除的 API 是专门用于控制 av7110 的 MPEG-2 解码器而编写的，从来没有被集成到 DVB 核心代码中去：av7110 在自己的内部代码中有一个针对这个驱动实现的专门版本。

此外，该 API 也从来没有完整的文档：有几个来自现在被删除的 API 的 ioctl 从来没有在官方 linux kernel 里面实现过，也没有在 spec 中描述过。目前的 upstream 维护者中没有一个人了解这些 ioctls 是做什么用的，我们也没有任何 av7110 硬件可以进行测试。

对于其中的一些说法，大家很明显是有分歧的，Moch 一再提出今后想自己来负责维护 av7110 的驱动程序。他也希望看到他的 saa716x 驱动（同样也实现了 DVB API）被合入 mainline，并说他也愿意作为它的维护者。据 Moch 说，有一个活跃的社区正在使用 VDR 的硬件，DVB API 很适合它的需求。但是 Chehab 说：

过去将 av7110 保留在内核中，一直是在浪费 upstream 上有限的开发资源。几年前，由于 year-2038 问题，我们需要修复 av7110 的 API。由于代码已经在那里很久缺乏维护了，我们时不时会遇到与它有关的 bug（甚至有些 security 问题）。如上所述，最近一次修改可能破坏了这个驱动程序，而在几次 Kernel review 中都没有人注意到。

Moch 对这一说法提出异议，并对 Chehab 对 media 子系统的处理有一些措辞非常强烈的抱怨，其中一部分他是向 Torvalds 提出的。显然，在这个话题中掺杂了一些长期争议。Torvalds 插进来澄清了一些事。他说，regression 政策只针对内核的 ABI，而这里 ABI 并没有发生变化。"旧程序仍旧可以继续工作"。他还感叹说 VDR 不应该直接使用内核的头文件，这不是正确的用法：

我们非常不建议用户空间的应用程序直接使用内核头文件，哪怕是像 glibc 这样的项目也应该是 copy 这些头文件，而不是直接 include 进去。

这正是因为对内核代码树的目录调整都不应该导致其他地方出现随机问题，而这些问题从内核的角度（或从另一端的角度）来看是很难测试和永远保持步调一致的。

但另一方面，有问题的头文件是位于 uapi 目录的。"虽然用户空间程序这样使用它们是会导致很多麻烦的，但我认为这种做法也不算是完全不合理的"。所以他把移动头文件的改动给 revert 掉了，同时保留了其他的改动不变（也就是 av7110 和 DVB API 文档仍然是被移到了 staging/）。他建议 VDR 和其他任何使用了头文件的应用程序都将这些文件复制到他们自己的代码 tree 中。他同意 Chehab 的意见，认为将 av7110 移出 main tree 是正确的做法：

我不认为将 av7110 驱动从 staging 中移回去是个有意义的做法，尽管它可能可以继续正常工作，但它 是 老旧代码，而且没有维护。并且我当然建议任何其他 mainline kernel 之外的驱动如果在使用这些没有版本实现的旧接口的话，都不应该继续使用了，毕竟没有什么其他东西实现了这些功能。

Torvalds 和 Chehab 似乎都忽略了 Moch 提出的维护驱动程序的建议，或者说没有完全接受，尽管他也许可以在 staging/ 中来作为这部分的维护者。保持驱动能一直正常工作，这是确保它不会被完全删除的一个好方法。然而，Moch 关于 av7110 最终命运的问题仍然没有得到回答：

这个驱动可以在 staging 区停留多长时间？如果我把它很好维护起来之后，你会把这个驱动程序从 staging 区移回来吗？如果一个驱动程序仍然有用户，并且有人自愿维护它，在一定时间后还要删除驱动程序，这是否是 Linux 的一个标准政策？

所以，至少现在 VDR 的用户还可以在最新的内核中进行编译。今后，复制了头文件之后应该也可以确保它继续能够成功编译。不过，如果驱动程序被删除的话，用户也将需要重新编译一个驱动程序，才能让一切正常工作起来。Chehab 说，他愿意参与讨论 DVB 的 API，"但是这样的 API 需要能够支持现代的嵌入式硬件，并且应该被设计成容易扩展来支持未来的需求"。这可能会导致需要重新制作一个 saa716x 驱动，这样它就可以被纳入 mainline，但无论如何这款硬件已经是相当古老的了，而且不清楚 VDR 社区是否有兴趣进行这类改动。

看到一个拥有活跃社区的仍然可用的驱动得到这样的待遇，着实有些令人惊讶，但 Chehab 坚持认为 DVB API 作为 media 子系统的一部分已经被废弃了。在这个主题中，有一股对多年来 DVB API 的处理和 Chehab 的处理方式表示不满的味道，但 Linux 维护者对于自己负责的子系统也总是有最大的权限。在这一点上，双方似乎都很固执己见，所以可能需要一些其他感兴趣的人站出来帮助找到一种可行的解决方案，否则的话 VDR 社区就需要继续使用那些处于 staging 的驱动，或者干脆完全脱离 mainline 的驱动了。

这个事件确实证明了内核里的 regression policy 扩充了适用场景。哪怕 Torvalds 对这里使用头文件的方式不满意，他也仍然不想导致一个现有的用户空间应用程序无法使用，因此进行了 revert 操作。我们不禁要问，还有多少其他的应用程序或 library 还没有了解到这个不要直接使用内核用户空间 API 头文件的原则呢？这可能会导致以后进行代码调整和清理工作的时候出现问题。

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

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

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