| 1 | |
| 2 |
|
| 3 | .. _coding_assistants:
|
| 4 |
|
| 5 | AI Coding Assistants
|
| 6 | ++++++++++++++++++++
|
| 7 |
|
| 8 | This document provides guidance for AI tools and developers using AI
|
| 9 | assistance when contributing to the Linux kernel.
|
| 10 |
|
| 11 | AI tools helping with Linux kernel development should follow the standard
|
| 12 | kernel development process:
|
| 13 |
|
| 14 | * Documentation/process/development-process.rst
|
| 15 | * Documentation/process/coding-style.rst
|
| 16 | * Documentation/process/submitting-patches.rst
|
| 17 |
|
| 18 | For guidelines on content generated by AI coding assistants see:
|
| 19 |
|
| 20 | * Documentation/process/generated-content.rst
|
| 21 |
|
| 22 | Licensing and Legal Requirements
|
| 23 | ================================
|
| 24 |
|
| 25 | All contributions must comply with the kernel's licensing requirements:
|
| 26 |
|
| 27 | * All code must be compatible with GPL-2.0-only
|
| 28 | * Use appropriate SPDX license identifiers
|
| 29 | * See Documentation/process/license-rules.rst for details
|
| 30 |
|
| 31 | Signed-off-by and Developer Certificate of Origin
|
| 32 | =================================================
|
| 33 |
|
| 34 | AI agents MUST NOT add Signed-off-by tags. Only humans can legally
|
| 35 | certify the Developer Certificate of Origin (DCO). The human submitter
|
| 36 | is responsible for:
|
| 37 |
|
| 38 | * Reviewing all AI-generated code
|
| 39 | * Ensuring compliance with licensing requirements
|
| 40 | * Adding their own Signed-off-by tag to certify the DCO
|
| 41 | * Taking full responsibility for the contribution
|
| 42 |
|
| 43 | Procedure for finding and fixing bugs
|
| 44 | =====================================
|
| 45 |
|
| 46 | When an AI assistant is used to find and fix bugs, it **MUST** follow at least
|
| 47 | these steps:
|
| 48 |
|
| 49 | 1. Before starting, read the whole process documentation listed above, as well
|
| 50 | as any other document mentioned in the request. Do not rely on isolated
|
| 51 | parts found by keyword search.
|
| 52 | 2. Note the commit ID and Locate a bug as instructed.
|
| 53 | 3. For any bug found that is not trivial, verify that it looks real by
|
| 54 | attempting to create a reproducer to demonstrate it. Lacking it may cause
|
| 55 | the report to be ignored, as many unverified bug reports sent to maintainers
|
| 56 | happen to be invalid. Stop here if it finally looks wrong.
|
| 57 | 4. Write a fix for the bug. This part is not optional: except in a few very
|
| 58 | rare cases, an AI assistant able to find a bug is able to fix it. Note that
|
| 59 | fixes written in the same session as used to find the bug will generally
|
| 60 | lead to better and more accurate fixes as the LLM's reasoning context
|
| 61 | remains present.
|
| 62 | 5. Build and verify that the fix works either using the reproducer or by
|
| 63 | re-running a complete analysis; drop any fix that doesn't work and try
|
| 64 | another one. The fix must not add build warnings and must pass the
|
| 65 | checkpatch.pl checks (see submitting-patches.rst).
|
| 66 | 6. Commit the working fix with a detailed message describing the problem, the
|
| 67 | solution and a Fixes tag. Do not add a Signed-off-by tag.
|
| 68 | 7. Identify the maintainers and lists using scripts/get_maintainer.pl.
|
| 69 | Documentation/process/security-bugs.rst shows how to do that.
|
| 70 | 8. Indicate what could not be done. If the fix could not be built or tested, or
|
| 71 | if no reproducer could be produced, say so explicitly: maintainers currently
|
| 72 | waste too much time analyzing unverified reports and untested fixes.
|
| 73 | 9. Read Documentation/process/threat-model.rst to determine whether the bug is
|
| 74 | a vulnerability or a regular bug, and leave the result to the reporter for
|
| 75 | review (the assistant must never send anything itself). Regular bugs are
|
| 76 | submitted as described in Documentation/process/submitting-patches.rst,
|
| 77 | vulnerabilities as described in Documentation/process/security-bugs.rst.
|