2 MEDIA SUBSYSTEM KERNEL INTERNAL API

本节包含有关多媒体子系统及其支持的驱动程序的使用信息。
请参阅：
Documentation/admin-guide/media/index.rst
• 了解有关多媒体子系统和支持的驱动程序的使用信息；
Documentation/userspace-api/media/index.rst
• 了解在多媒体设备上使用的用户空间API。
2.1 Media Subsystem Profile
2.1.1 Overview
多媒体子系统涵盖了对各种设备的支持：流捕获、模拟和数字电视流、摄像头、遥控器、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，这意味着一旦提交补丁，邮件将首先被邮件列表服务器接受，然后在一段时间后应该出现在以下位置：
• https://patchwork.linuxtv.org/project/linux-media/list/
如果几分钟后未自动显示，请检查您的提交是否有误。请检查电子邮件是否为纯文本，并且您的电子邮件程序是否在投诉或重新提交之前操纵空格。
您可以通过查看以下内容来检查邮件列表服务器是否接受了您的补丁：
• https://lore.kernel.org/linux-media/
2.1.1.1 Media maintainers
在多媒体子系统中，我们有一组高级开发人员负责对驱动程序进行代码审查（也称为子维护者），另一个高级开发人员负责整个子系统。对于核心更改，尽可能多的多媒体维护者进行审核。
负责特定子系统区域的多媒体维护者有：
• 远程控制器（红外线）：Sean Young <sean@mess.org>
• HDMI CEC：Hans Verkuil <hverkuil@xs4all.nl>
• 媒体控制器驱动程序：Laurent Pinchart <laurent.pinchart@ideasonboard.com>
• ISP、v4l2异步、v4l2-fwnode、v4l2-flash-led-class和传感器驱动程序：Sakari Ailus <sakari.ailus@linux.intel.com>
• V4L2驱动程序和核心V4L2框架：Hans Verkuil <hverkuil@xs4all.nl>
子系统维护者是：Mauro Carvalho Chehab <mchehab@kernel.org>
多媒体维护者可以根据需要将补丁委派给其他多媒体维护者。在这种情况下，checkpatch的委派字段指示当前负责审核补丁的人。
2.1.2 Submit Checklist Addendum        //提交检查清单补遗
更改开放固件/设备树绑定的补丁必须由设备树维护者审核。因此，当这些补丁通过device-tree@vger.kernel.org邮件列表提交时，应将DT维护者添加为抄送人。
https://git.linuxtv.org/v4l-utils.git/上有一组符合性工具，应该用来检查驱动程序是否正确实现了媒体API。

 正在开发其他符合性工具，以检查子系统的其他部分。这些测试需要在补丁上游之前通过。
此外，请注意，我们使用以下方式构建内核：

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

Where the check script is:

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

请注意，不要没有非常好的理由就在您的补丁中引入新的警告。
2.1.2.1 Style Cleanup Patches    //代码风格清理补丁
当代码风格更改会影响到其他更改的文件时，欢迎一起进行代码风格清理。
我们可以接受纯粹的独立代码风格清理，但是最好是将其作为整个子系统的一个补丁（如果清理量很小），或者至少按目录分组。例如，如果您正在对drivers/media下的驱动程序进行大规模的清理更改，则请发送一个单独的补丁用于drivers/media/pci下的所有驱动程序，另一个补丁用于drivers/media/usb等。
2.1.2.2 Coding Style Addendum

媒体开发使用checkpatch.pl在strict模式下验证代码风格，例如:

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

原则上，补丁应遵循编码样式规则，但如果有充分的理由，可以允许例外。在这种情况下，维护者和评审人员可能会对不解决checkpatch.pl问题的理由进行质疑。请注意，这里的目标是提高代码可读性。在一些情况下，checkpatch.pl可能实际上会指向更糟糕的地方。因此，您应该用好判断力。请注意，仅解决一个checkpatch.pl问题（无论何种类型）可能会导致每行超过80个字符。虽然这并不是严格禁止的，但应努力保持每行80个字符以内。这包括使用重构代码以减少缩进、更短的变量或函数名称，最后但并非最不重要的是简单地换行。特别地，在以下情况下，我们接受超过80列的行：
• 字符串，因为它们不应因长度限制而被打断；
• 当函数或变量名需要具有较大的标识符名称时，可以超过80列，因为这样更难遵守80列的限制；
• 在算术表达式中，当断行使它们更难阅读时；
• 当它们避免行以开放括号或开放方括号结束时。
2.1.3 关键周期日期
新提交可以随时发送，但是如果它们打算在下一个合并窗口中纳入，则应在-rc5之前发送，并在-linux-media分支中通过-rc6稳定。
2.1.4 审查节奏
只要您的补丁在https://patchwork.linuxtv.org上，它迟早会被处理，因此您不需要重新提交补丁。
除了错误修复外，在-rc6和下一个-rc1之间，我们通常不会向开发树中添加新的补丁。
请注意，媒体子系统是一个高流量的子系统，因此我们可能需要一些时间才能审查您的补丁。如果在几周内没有得到反馈，请随时提醒我们或向其他开发人员公开添加Reviewed-by和更重要的Tested-by:标记。
请注意，我们期望对Tested-by:进行详细说明，识别使用了哪些板子以及测试内容是什么。