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. 提交清单附录

更改 Open Firmware/设备树绑定的补丁必须由设备树维护者审查。因此，当通过 devicetree@vger.kernel.org 邮件列表提交这些补丁时，应该抄送 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/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 之间向开发树添加新补丁。

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

请注意，我们期望 Tested-by: 的详细描述，说明在测试中使用了哪些板以及测试的内容。