Documentation/process/generated-content.rst

Source file repositories/reference/linux-study-clean/Documentation/process/generated-content.rst

File Facts

System
Linux kernel
Corpus path
Documentation/process/generated-content.rst
Extension
.rst
Size
4541 bytes
Lines
110
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.

Dependency Surface

Detected Declarations

Annotated Snippet

============================================
Kernel Guidelines for Tool-Generated Content
============================================

Purpose
=======

Kernel contributors have been using tooling to generate contributions
for a long time. These tools can increase the volume of contributions.
At the same time, reviewer and maintainer bandwidth is a scarce
resource. Understanding which portions of a contribution come from
humans versus tools is helpful to maintain those resources and keep
kernel development healthy.

The goal here is to clarify community expectations around tools. This
lets everyone become more productive while also maintaining high
degrees of trust between submitters and reviewers.

Out of Scope
============

These guidelines do not apply to tools that make trivial tweaks to
preexisting content. Nor do they pertain to tooling that helps with
menial tasks. Some examples:

 - Spelling and grammar fix ups, like rephrasing to imperative voice
 - Typing aids like identifier completion, common boilerplate or
   trivial pattern completion
 - Purely mechanical transformations like variable renaming
 - Reformatting, like running Lindent, ``clang-format`` or
   ``rust-fmt``

Even whenever your tool use is out of scope, you should still always
consider if it would help reviewing your contribution if the reviewer
knows about the tool that you used.

In Scope
========

These guidelines apply when a meaningful amount of content in a kernel
contribution was not written by a person in the Signed-off-by chain,
but was instead created by a tool.

Detection of a problem and testing the fix for it is also part of the
development process; if a tool was used to find a problem addressed by
a change, that should be noted in the changelog. This not only gives
credit where it is due, it also helps fellow developers find out about
these tools.

Some examples:
 - Any tool-suggested fix such as ``checkpatch.pl --fix``
 - Coccinelle scripts
 - A chatbot generated a new function in your patch to sort list entries.
 - A .c file in the patch was originally generated by a coding
   assistant but cleaned up by hand.
 - The changelog was generated by handing the patch to a generative AI
   tool and asking it to write the changelog.
 - The changelog was translated from another language.

If in doubt, choose transparency and assume these guidelines apply to
your contribution.

Guidelines
==========

First, read the Developer's Certificate of Origin:
Documentation/process/submitting-patches.rst. Its rules are simple
and have been in place for a long time. They have covered many
tool-generated contributions. Ensure that you understand your entire
submission and are prepared to respond to review comments.

Annotation

Implementation Notes