Documentation/translations/zh_TW/process/3.Early-stage.rst
Source file repositories/reference/linux-study-clean/Documentation/translations/zh_TW/process/3.Early-stage.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/translations/zh_TW/process/3.Early-stage.rst- Extension
.rst- Size
- 9486 bytes
- Lines
- 173
- 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
.. include:: ../disclaimer-zh_TW.rst
:Original: :ref:`Documentation/process/3.Early-stage.rst <development_early_stage>`
:Translator:
時奎亮 Alex Shi <alex.shi@linux.alibaba.com>
:校譯:
吳想成 Wu XiangCheng <bobwxc@email.cn>
胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>
.. _tw_development_early_stage:
早期規劃
========
當考慮一個Linux內核開發項目時,很可能會直接跳進去開始編碼。然而,與任何重要
的項目一樣,許多成功的基礎最好是在第一行代碼編寫之前就打下。在早期計劃和
溝通中花費一些時間可以在之後節省更多的時間。
搞清問題
--------
與任何工程項目一樣,成功的內核改善從清晰描述要解決的問題開始。在某些情況
下,這個步驟很容易:例如當某個特定硬件需要驅動程序時。不過,在其他情況下,
很容易將實際問題與建議的解決方案混在一起,這可能會導致麻煩。
舉個例子:幾年前,Linux音頻的開發人員尋求一種方法來運行應用程序,而不會因
系統延遲過大而導致退出或其他問題。他們得到的解決方案是一個連接到Linux安全
模塊(LSM)框架中的內核模塊;這個模塊可以配置爲允許特定的應用程序訪問實時
調度程序。這個模塊被實現併發到linux-kernel郵件列表,在那裏它立即遇到了麻煩。
對於音頻開發人員來說,這個安全模塊足以解決他們當前的問題。但是,對於更廣泛的
內核社區來說,這被視爲對LSM框架的濫用(LSM框架並不打算授予他們原本不具備的
進程特權),並對系統穩定性造成風險。他們首選的解決方案包括短期的通過rlimit
機制進行實時調度訪問,以及長期的減少延遲的工作。
然而,音頻社區無法超越他們實施的特定解決方案來看問題;他們不願意接受替代方案。
由此產生的分歧使這些開發人員對整個內核開發過程感到失望;其中一個開發人員返回
到audio列表併發布了以下內容:
有很多非常好的Linux內核開發人員,但他們往往會被一羣傲慢的傻瓜所壓倒。
試圖向這些人傳達用戶需求是浪費時間。他們太“聰明”了,根本聽不到少數
人的話。
(http://lwn.net/Articles/131776/)
實際情況卻是不同的;與特定模塊相比,內核開發人員更關心繫統穩定性、長期維護
以及找到問題的正確解決方案。這個故事的寓意是把重點放在問題上——而不是具體的
解決方案上——並在開始編寫代碼之前與開發社區討論這個問題。
因此,在考慮一個內核開發項目時,我們應該得到一組簡短問題的答案:
- 需要解決的問題究竟是什麼?
- 受此問題影響的用戶有哪些?解決方案應該解決哪些使用案例?
- 內核現在爲何沒能解決這個問題?
只有這樣,才能開始考慮可能的解決方案。
早期討論
--------
在計劃內核開發項目時,在開始實施之前與社區進行討論是很有意義的。早期溝通可以
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.