1. 媒体子系统概况

1.1. 概述

媒体子系统涵盖了对各种设备的支持：流捕获、模拟和数字电视流、摄像头、遥控器、HDMI CEC 和媒体管道控制。

它主要涵盖以下目录的内容

  • drivers/media

  • drivers/staging/media

  • Documentation/admin-guide/media

  • Documentation/driver-api/media

  • Documentation/userspace-api/media

  • Documentation/devicetree/bindings/media/[1]

  • include/media

媒体用户空间和内核 API 都有文档记录，并且文档必须与 API 更改保持同步。这意味着所有向子系统添加新功能的补丁也必须对相应的 API 文件进行更改。

由于媒体子系统的大小和范围很广，媒体的维护模型是让子维护者对子系统的特定方面有广泛的了解。子维护者的任务是审查补丁，如果补丁遵循子系统规则并正确使用媒体内核和用户空间 API，则向用户提供反馈。

媒体子系统的补丁必须以纯文本电子邮件的形式发送到媒体邮件列表 linux-media@vger.kernel.org。带有 HTML 的电子邮件将被邮件服务器自动拒绝。明智的做法是抄送子维护者。

媒体的工作流程在很大程度上依赖于 Patchwork，这意味着一旦提交补丁，电子邮件将首先被邮件列表服务器接受，过一段时间后，它应该会出现在

如果它在几分钟后没有自动出现在那里，那么可能是您的提交出了问题。请检查电子邮件是否为纯文本[2]，以及您的电子邮件程序是否没有在您抱怨或重新提交之前破坏空格。

您可以通过查看以下内容来检查邮件列表服务器是否接受了您的补丁

1.1.1. 媒体维护者

在媒体子系统中，我们有一组负责在驱动程序中进行代码审查的资深开发人员（也称为子维护者），以及另一位负责整个子系统的资深开发人员。对于核心更改，在可能的情况下，多个媒体维护者会进行审查。

在子系统的特定领域工作的媒体维护者是

子系统维护者是

Mauro Carvalho Chehab <mchehab@kernel.org>

媒体维护者可以根据需要将补丁委派给其他媒体维护者。在这种情况下，checkpatch 的 delegate 字段指示当前负责审查补丁的人员。

1.2. 提交清单附录

更改开放固件/设备树绑定的补丁必须由设备树维护者审查。因此，当通过 [email protected] 邮件列表提交这些补丁时，应抄送 DT 维护者。

在 https://git.linuxtv.org/v4l-utils.git/ 上有一组合规性工具，应该使用这些工具来检查驱动程序是否正确实现了媒体 API

类型

工具

V4L2 驱动程序[3]

v4l2-compliance

V4L2 虚拟驱动程序

contrib/test/test-media

CEC 驱动程序

cec-compliance

其他合规性工具正在开发中，以检查子系统的其他部分。

这些测试需要通过，然后补丁才能进入上游。

另外，请注意我们使用以下命令构建内核

make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script

其中检查脚本位于

#!/bin/bash
/devel/smatch/smatch -p=kernel $@ >&2
/devel/sparse/sparse $@ >&2

请确保在您的补丁中不要引入新的警告，除非有非常充分的理由。

1.2.1. 样式清理补丁

当样式更改会影响的文件发生其他更改时，欢迎进行样式清理。

我们可能会接受纯粹的独立样式清理，但理想情况下，它们应该是一个针对整个子系统的补丁（如果清理量很小），或者至少按目录分组。因此，例如，如果您在 drivers/media 下的 drivers 中进行大型清理更改集，请为 drivers/media/pci 下的所有驱动程序发送一个补丁，为 drivers/media/usb 下的所有驱动程序发送另一个补丁，依此类推。

1.2.2. 编码样式附录

媒体开发使用严格模式下的 checkpatch.pl 来验证代码样式，例如

$ ./scripts/checkpatch.pl --strict --max-line-length=80

原则上，补丁应遵循编码样式规则，但如果有充分理由，则允许例外。在这种情况下，维护者和审查人员可能会质疑不处理 checkpatch.pl 的理由。

请注意，这里的目标是提高代码的可读性。在少数情况下，checkpatch.pl 实际上可能会指出看起来更糟糕的事情。因此，您应该运用常识。

请注意，单独解决一个 checkpatch.pl 问题（任何类型）可能会导致每行超过 80 个字符。虽然这不是严格禁止的，但应努力保持在每行 80 个字符内。这可能包括使用重构代码，从而减少缩进、缩短变量或函数名称，最后但并非最不重要的是，简单地换行。

特别是，我们接受超过 80 列的行

  • 在字符串中，因为它们不应因行长度限制而中断；

  • 当函数或变量名需要有一个很大的标识符名称时，这使得难以满足 80 列的限制；

  • 在算术表达式中，当换行使它们更难阅读时；

  • 当它们避免行以左括号或左方括号结尾时。

1.3. 关键周期日期

新的提交可以随时发送，但如果它们希望进入下一个合并窗口，则应在 -rc5 之前发送，并且理想情况下在 -rc6 之前在 linux-media 分支中稳定下来。

1.4. 审查节奏

只要您的补丁在 https://patchwork.linuxtv.org 上，它应该迟早会被处理，因此您不需要重新提交补丁。

除了错误修复之外，我们通常不会在 -rc6 和下一个 -rc1 之间向开发树添加新的补丁。

请注意，媒体子系统是一个高流量的子系统，因此我们可能需要一段时间才能审查您的补丁。如果在几周内没有收到反馈，请随时 ping 我们，或要求其他开发人员公开添加 Reviewed-by 和更重要的 Tested-by: 标签。

请注意，我们期望对 Tested-by: 进行详细描述，说明测试时使用了哪些板卡以及测试了什么。