Documentation/driver-api/media/maintainer-entry-profile.rst
Source file repositories/reference/linux-study-clean/Documentation/driver-api/media/maintainer-entry-profile.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/driver-api/media/maintainer-entry-profile.rst- Extension
.rst- Size
- 21550 bytes
- Lines
- 546
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. SPDX-License-Identifier: GPL-2.0
Media Subsystem Profile
=======================
Overview
--------
The Linux Media Community (aka: the LinuxTV Community) is formed by
developers working on Linux Kernel Media Subsystem, together with users
who also play an important role in testing the code.
The Media Subsystem has code to support a wide variety of media-related
devices: stream capture, analog and digital TV streams, cameras,
video codecs, video processing (resizers, etc.), radio, remote controllers,
HDMI CEC and media pipeline control.
The Media Subsystem consists of the following directories in the kernel
tree:
- drivers/media
- drivers/staging/media
- include/media
- Documentation/devicetree/bindings/media/\ [1]_
- Documentation/admin-guide/media
- Documentation/driver-api/media
- Documentation/userspace-api/media
.. [1] Device tree bindings are maintained by the
OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS maintainers
(see the MAINTAINERS file). So, changes there must be reviewed
by them before being merged into the media subsystem's development
tree.
Both media userspace and Kernel APIs are documented and the documentation
must be kept in sync with the API changes. It means that all patches that
add new features to the subsystem must also bring changes to the
corresponding API documentation.
Media Maintainers
-----------------
Media Maintainers are not just people capable of writing code, but they
are developers who have demonstrated their ability to collaborate with
the team, get the most knowledgeable people to review code, contribute
high-quality code, and follow through to fix issues (in code or tests).
Due to the size and wide scope of the media subsystem, multiple layers of
maintainers are required, each with their own areas of expertise:
- **Media Driver Maintainer**:
Responsible for one or more drivers within the Media Subsystem. They
are listed in the MAINTAINERS file as maintainer for those drivers. Media
Driver Maintainers review patches for those drivers, provide feedback if
patches do not follow the subsystem rules, or are not using the
media kernel or userspace APIs correctly, or if they have poor code
quality.
If you are the patch author, you work with other Media
Maintainers to ensure your patches are reviewed.
Some Media Driver Maintainers have additional responsibilities. They have
been granted Patchwork access and keep
`Patchwork <https://patchwork.linuxtv.org/project/linux-media/list/>`_
up to date, decide when patches are ready for merging, and create Pull
Requests for the Media Subsystem Maintainers to merge.
- **Media Core Maintainer**:
Media Driver Maintainers with Patchwork access who are also responsible for
one or more media core frameworks.
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.