Documentation/translations/zh_TW/process/submitting-patches.rst

Source file repositories/reference/linux-study-clean/Documentation/translations/zh_TW/process/submitting-patches.rst

File Facts

System
Linux kernel
Corpus path
Documentation/translations/zh_TW/process/submitting-patches.rst
Extension
.rst
Size
33205 bytes
Lines
660
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

.. SPDX-License-Identifier: GPL-2.0-or-later

.. include:: ../disclaimer-zh_TW.rst

.. _tw_submittingpatches:

:Original: Documentation/process/submitting-patches.rst

:譯者:
 - 鍾宇 TripleX Chung <xxx.phy@gmail.com>
 - 時奎亮 Alex Shi <alexs@kernel.org>
 - 吳想成 Wu XiangCheng <bobwxc@email.cn>

:校譯:
 - 李陽 Li Yang <leoyang.li@nxp.com>
 - 王聰 Wang Cong <xiyou.wangcong@gmail.com>
 - 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>


提交補丁：如何讓你的改動進入內核
================================

對於想要將改動提交到 Linux 內核的個人或者公司來說，如果不熟悉“規矩”，
提交的流程會讓人畏懼。本文檔包含了一系列建議，可以大大提高你
的改動被接受的機會.

本文檔以較爲簡潔的行文給出了大量建議。關於內核開發流程如何進行的詳細信息，
參見： Documentation/translations/zh_CN/process/development-process.rst 。
Documentation/translations/zh_CN/process/submit-checklist.rst 給出了一系列
提交補丁之前要檢查的事項。設備樹相關的補丁，請參閱
Documentation/devicetree/bindings/submitting-patches.rst 。

本文檔假設您正在使用 ``git`` 準備你的補丁。如果您不熟悉 ``git`` ，最好學習
如何使用它，這將使您作爲內核開發人員的生活變得更加輕鬆。

部分子系統和維護人員的樹有一些關於其工作流程和要求的額外信息，請參閱
Documentation/process/maintainer-handbooks.rst 。

獲取當前源碼樹
--------------

如果您手頭沒有當前內核源代碼的存儲庫，請使用 ``git`` 獲取一份。您需要先獲取
主線存儲庫，它可以通過以下命令拉取::

    git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

但是，請注意，您可能不想直接針對主線樹進行開發。大多數子系統維護人員運
行自己的樹，並希望看到針對這些樹準備的補丁。請參見MAINTAINERS文件中子系
統的 **T:** 項以查找該樹，或者直接詢問維護者該樹是否未在其中列出。

.. _tw_describe_changes:

描述你的改動
------------

描述你的問題。無論您的補丁是一行錯誤修復還是5000行新功能，都必須有一個潛在
的問題激勵您完成這項工作。說服審閱者相信有一個問題值得解決，讓他們讀完第一段
後就能明白這一點。

描述用戶可見的影響。直接崩潰和鎖定是相當有說服力的，但並不是所有的錯誤都那麼
明目張膽。即使在代碼審閱期間發現了這個問題，也要描述一下您認爲它可能對用戶產
生的影響。請記住，大多數Linux安裝運行的內核來自二級穩定樹或特定於供應商/產品
的樹，只從上游精選特定的補丁，因此請包含任何可以幫助您將更改定位到下游的內容：
觸發的場景、DMESG的摘錄、崩潰描述、性能迴歸、延遲尖峯、鎖定等。

質量優化和權衡。如果您聲稱在性能、內存消耗、堆棧佔用空間或二進制大小方面有所
改進，請包括支持它們的數據。但也要描述不明顯的成本。優化通常不是零成本的，而是
在CPU、內存和可讀性之間進行權衡；或者，做探索性的工作，在不同的工作負載之間進
行權衡。請描述優化的預期缺點，以便審閱者可以權衡成本和收益。

Annotation

Implementation Notes