Dear Jonathan, dear Federico, dear Alex, dear Yanteng, dear Hu,
Here is an attempt to delete submitting-drivers with some improvements
and clean-up in other documentation places to convince ourselves that
nothing valuable is lost when deleting this checklist.
Patch 1, 2 and 3 is just basic clean-up before adding a new reference (see
Patch 4). Patch 4 adds the one reference from submitting-drivers, not
already mentioned elsewhere in the repository. Patch 5 updates a confusing
statement in devices.rst from earlier .txt/.tex distinction times to the
new state now with Sphinx & .rst.
Patch 6 finally deletes the outdated document, with a cross-check what is
covered elsewhere and few open questions (see below).
Patch 7 and 8 have been reworked with the native-speaking doc maintainers;
they cause no new warnings and are ready to pick,
Patch 9 to 11 are weak attempts to adjust the translation, but they need
to be taken further by others due to my lack of knowledge on the other
languages. They would currently also cause new warnings in the doc-build
right now. They should not be picked if there is no one to continue
to adjust the text and fix the warnings on broken references.
I hope that patches 1 to 8 can be picked into doc-next, and then we see
how to fix up the translations as well.
Further open considerations:
- Should we add some subsection/paragraph on Testing to "A guide on
kernel development process", which then further refers to
power/drivers-testing.rst for testing the power management of the
driver?
(I am bit surprised that code-checking tools are mentioned, but not
much more on actual kernel testing is mentioned there.)
- Should we be a bit more explicit on how and when to add a MAINTAINERS
entry, besides the short note in 6.Followthrough.rst?
- Translations of submitting-patches.rst and 8.Conclusion.rst in Asian
languages include a reference to submitting-drivers, I cannot adjust
the text due to my lack of understanding of the surrounding text.
zh_CN/process/8.Conclusion.rst:和 :ref:`Documentation/translations/zh_CN/process/submitting-drivers.rst <cn_submittingdrivers>`
zh_CN/process/submitting-patches.rst::ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
zh_TW/process/8.Conclusion.rst:和 :ref:`Documentation/translations/zh_TW/process/submitting-drivers.rst <tw_submittingdrivers>`
zh_TW/process/submitting-patches.rst::ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
This currently lead to some new warnings in this patch series. I hope
some native speakers of those languages can help out here. The other
references were adjusted on a best guess of the text, which should be
confirmed by native-speaking reviewers.
Generally, I hope we are now all well-convinced to delete submitting-drivers.
Anything else needed to be convinced? I put already some thought into it,
and I am willing to add more content in other documents to properly get rid
of this outdated one here, or just starting writing a good new checklist
for driver submission that reflect what the majority of maintainers want
to see submitters do.
Link to RFC patch series:
https://lore.kernel.org/linux-doc/[email protected]/
rfc -> v1: improved Italian and Japanese translation
Best regards,
Lukas
Lukas Bulwahn (11):
docs: kernel-docs: order reference from newest to oldest
docs: kernel-docs: shorten the lengthy doc title
docs: kernel-docs: reflect that it is community-maintained
docs: kernel-docs: add a reference mentioned in submitting-drivers.rst
docs: admin: devices: drop confusing outdated statement on Latex
docs: process: remove outdated submitting-drivers.rst
docs: it_IT: align to submitting-drivers removal
docs: ja_JP: howto: remove reference to removed submitting-drivers
docs: ko_KR: howto: remove reference to removed submitting-drivers
docs: zh_CN: align to submitting-drivers removal
docs: zh_TW: align to submitting-drivers removal
Documentation/admin-guide/devices.rst | 7 +-
Documentation/hwmon/submitting-patches.rst | 1 -
Documentation/kernel-hacking/hacking.rst | 3 +-
Documentation/process/5.Posting.rst | 3 +-
Documentation/process/8.Conclusion.rst | 16 +-
Documentation/process/howto.rst | 4 +-
Documentation/process/index.rst | 1 -
Documentation/process/kernel-docs.rst | 62 +++---
Documentation/process/submitting-drivers.rst | 194 ------------------
Documentation/process/submitting-patches.rst | 5 +-
.../it_IT/kernel-hacking/hacking.rst | 3 +-
.../translations/it_IT/process/5.Posting.rst | 5 +-
.../it_IT/process/8.Conclusion.rst | 5 +-
.../translations/it_IT/process/howto.rst | 3 +-
.../translations/it_IT/process/index.rst | 1 -
.../it_IT/process/submitting-drivers.rst | 16 --
.../it_IT/process/submitting-patches.rst | 6 +-
Documentation/translations/ja_JP/howto.rst | 4 +-
Documentation/translations/ko_KR/howto.rst | 2 +-
.../zh_CN/kernel-hacking/hacking.rst | 3 +-
.../translations/zh_CN/process/5.Posting.rst | 3 +-
.../translations/zh_CN/process/howto.rst | 1 -
.../translations/zh_CN/process/index.rst | 1 -
.../zh_CN/process/submitting-drivers.rst | 160 ---------------
.../translations/zh_TW/process/5.Posting.rst | 3 +-
.../translations/zh_TW/process/howto.rst | 1 -
.../translations/zh_TW/process/index.rst | 1 -
.../zh_TW/process/submitting-drivers.rst | 164 ---------------
28 files changed, 66 insertions(+), 612 deletions(-)
delete mode 100644 Documentation/process/submitting-drivers.rst
delete mode 100644 Documentation/translations/it_IT/process/submitting-drivers.rst
delete mode 100644 Documentation/translations/zh_CN/process/submitting-drivers.rst
delete mode 100644 Documentation/translations/zh_TW/process/submitting-drivers.rst
--
2.17.1
Commit 31b24bee3357 ("docs: add a warning to submitting-drivers.rst")
in October 2016 already warns "This (...) should maybe just be deleted,
but I'm not quite ready to do that yet".
Maybe, six years ago, we were not ready but let us remove old content
for the better now and structure and maintain less content in the kernel
documentation with a better result.
Drop this already outdated document and adjust all textual references.
Here is an argument why deleting the content will not remove any useful
information to the existing kernel documentation, individually broken down
for each section.
Section "Allocating Device Numbers" refers to https://www.lanana.org/, and
then refers to Documentation/admin-guide/devices.rst.
However, the devices.rst clearly states:
"The version of this document at lanana.org is no longer maintained."
Everything needed for submitting drivers is already stated in devices.rst
and the reference to https://www.lanana.org/ is outdated, and should be
just deleted.
Section "Who To Submit Drivers To" is all about Linux 2.0 - 2.6, before
the new release version scheme; the mentioned developers are still around,
but actually not the first developers to contact anymore.
Section "What Criteria Determine Acceptance" has a few bullet points:
Licensing and Copyright is well-covered in process/kernel-license.rst.
Interfaces, Code, Portability, Clarity state some obvious things about
ensuring kernel code quality.
Control suggests to add a MAINTAINERS entry, which is already mentioned in
6.Followthrough.rst: "... added yourself to the MAINTAINERS file..."
PM support states a bit about implementing and testing power management of
a driver, it remains an open question where to place that in the process
documents. Driver developers interested in power management will find the
corresponding part on power management in the kernel documentation anyway.
In section "What Criteria Do Not Determine Acceptance", the points Vendor
and Author states something basic consequence of the kernel being an
open-source community software development. Probably no need to mention it
nowadays.
Section "Resources" lists resources that are also mentioned elsewhere more
central.
- Linux kernel tree and mailing list is mentioned in many places.
- https://lwn.net/Kernel/LDD3/ is mentioned in
Documentation/process/kernel-docs.rst.
- https://lwn.net/ is mentioned in:
- Documentation/process/8.Conclusion.rst
- Documentation/process/kernel-docs.rst
- https://kernelnewbies.org/ is mentioned in:
- Documentation/process/8.Conclusion.rst
- Documentation/process/kernel-docs.rst
- http://www.linux-usb.org/ is mentioned in
Documentation/driver-api/usb/usb.rst
- https://landley.net/kdocs/ols/2002/ols2002-pages-545-555.pdf
is mentioned in Documentation/process/kernel-docs.rst
- https://kernelnewbies.org/KernelJanitors is mentioned in
Documentation/process/howto.rst
- https://git-scm.com/ is mentioned in
- Documentation/process/2.Process.rst
- Documentation/process/7.AdvancedTopics.rst
- Documentation/process/howto.rst
Signed-off-by: Lukas Bulwahn <[email protected]>
---
Documentation/hwmon/submitting-patches.rst | 1 -
Documentation/kernel-hacking/hacking.rst | 3 +-
Documentation/process/5.Posting.rst | 3 +-
Documentation/process/8.Conclusion.rst | 16 +-
Documentation/process/howto.rst | 4 +-
Documentation/process/index.rst | 1 -
Documentation/process/submitting-drivers.rst | 194 -------------------
Documentation/process/submitting-patches.rst | 5 +-
8 files changed, 13 insertions(+), 214 deletions(-)
delete mode 100644 Documentation/process/submitting-drivers.rst
diff --git a/Documentation/hwmon/submitting-patches.rst b/Documentation/hwmon/submitting-patches.rst
index 9a218ea996d8..d953ee763c96 100644
--- a/Documentation/hwmon/submitting-patches.rst
+++ b/Documentation/hwmon/submitting-patches.rst
@@ -12,7 +12,6 @@ increase the chances of your change being accepted.
* It should be unnecessary to mention, but please read and follow:
- Documentation/process/submit-checklist.rst
- - Documentation/process/submitting-drivers.rst
- Documentation/process/submitting-patches.rst
- Documentation/process/coding-style.rst
diff --git a/Documentation/kernel-hacking/hacking.rst b/Documentation/kernel-hacking/hacking.rst
index ebd9d90882ea..9a1f020c8449 100644
--- a/Documentation/kernel-hacking/hacking.rst
+++ b/Documentation/kernel-hacking/hacking.rst
@@ -755,8 +755,7 @@ make a neat patch, there's administrative work to be done:
it implies a more-than-passing commitment to some part of the code.
- Finally, don't forget to read
- ``Documentation/process/submitting-patches.rst`` and possibly
- ``Documentation/process/submitting-drivers.rst``.
+ ``Documentation/process/submitting-patches.rst``
Kernel Cantrips
===============
diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst
index bd36ecb29409..906235c11c24 100644
--- a/Documentation/process/5.Posting.rst
+++ b/Documentation/process/5.Posting.rst
@@ -10,8 +10,7 @@ of conventions and procedures which are used in the posting of patches;
following them will make life much easier for everybody involved. This
document will attempt to cover these expectations in reasonable detail;
more information can also be found in the files
-:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`,
-:ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
+:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
and :ref:`Documentation/process/submit-checklist.rst <submitchecklist>`.
diff --git a/Documentation/process/8.Conclusion.rst b/Documentation/process/8.Conclusion.rst
index b32a40215858..8c847dffe76b 100644
--- a/Documentation/process/8.Conclusion.rst
+++ b/Documentation/process/8.Conclusion.rst
@@ -5,15 +5,13 @@ For more information
There are numerous sources of information on Linux kernel development and
related topics. First among those will always be the Documentation
-directory found in the kernel source distribution. The top-level :ref:`process/howto.rst <process_howto>`
-file is an important starting point; :ref:`process/submitting-patches.rst <submittingpatches>`
-and :ref:`process/submitting-drivers.rst <submittingdrivers>`
-are also something which all kernel developers should
-read. Many internal kernel APIs are documented using the kerneldoc
-mechanism; "make htmldocs" or "make pdfdocs" can be used to generate those
-documents in HTML or PDF format (though the version of TeX shipped by some
-distributions runs into internal limits and fails to process the documents
-properly).
+directory found in the kernel source distribution. Start with the
+top-level :ref:`process/howto.rst <process_howto>`; also read
+:ref:`process/submitting-patches.rst <submittingpatches>`. Many internal
+kernel APIs are documented using the kerneldoc mechanism; "make htmldocs"
+or "make pdfdocs" can be used to generate those documents in HTML or PDF
+format (though the version of TeX shipped by some distributions runs into
+internal limits and fails to process the documents properly).
Various web sites discuss kernel development at all levels of detail. Your
author would like to humbly suggest https://lwn.net/ as a source;
diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index e4beeca57e5f..cd6997a9d203 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -105,8 +105,8 @@ required reading:
patches if these rules are followed, and many people will only
review code if it is in the proper style.
- :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` and :ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
- These files describe in explicit detail how to successfully create
+ :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
+ This file describes in explicit detail how to successfully create
and send a patch, including (but not limited to):
- Email contents
diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
index 3587dae4d0ef..2ba2a1582bbe 100644
--- a/Documentation/process/index.rst
+++ b/Documentation/process/index.rst
@@ -40,7 +40,6 @@ Other guides to the community that are of interest to most developers are:
:maxdepth: 1
changes
- submitting-drivers
stable-api-nonsense
management-style
stable-kernel-rules
diff --git a/Documentation/process/submitting-drivers.rst b/Documentation/process/submitting-drivers.rst
deleted file mode 100644
index 8413b693d10d..000000000000
--- a/Documentation/process/submitting-drivers.rst
+++ /dev/null
@@ -1,194 +0,0 @@
-.. _submittingdrivers:
-
-Submitting Drivers For The Linux Kernel
-=======================================
-
-This document is intended to explain how to submit device drivers to the
-various kernel trees. Note that if you are interested in video card drivers
-you should probably talk to XFree86 (https://www.xfree86.org/) and/or X.Org
-(https://x.org/) instead.
-
-.. note::
-
- This document is old and has seen little maintenance in recent years; it
- should probably be updated or, perhaps better, just deleted. Most of
- what is here can be found in the other development documents anyway.
-
- Oh, and we don't really recommend submitting changes to XFree86 :)
-
-Also read the :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
-document.
-
-
-Allocating Device Numbers
--------------------------
-
-Major and minor numbers for block and character devices are allocated
-by the Linux assigned name and number authority (currently this is
-Torben Mathiasen). The site is https://www.lanana.org/. This
-also deals with allocating numbers for devices that are not going to
-be submitted to the mainstream kernel.
-See :ref:`Documentation/admin-guide/devices.rst <admin_devices>`
-for more information on this.
-
-If you don't use assigned numbers then when your device is submitted it will
-be given an assigned number even if that is different from values you may
-have shipped to customers before.
-
-Who To Submit Drivers To
-------------------------
-
-Linux 2.0:
- No new drivers are accepted for this kernel tree.
-
-Linux 2.2:
- No new drivers are accepted for this kernel tree.
-
-Linux 2.4:
- If the code area has a general maintainer then please submit it to
- the maintainer listed in MAINTAINERS in the kernel file. If the
- maintainer does not respond or you cannot find the appropriate
- maintainer then please contact Willy Tarreau <[email protected]>.
-
-Linux 2.6 and upper:
- The same rules apply as 2.4 except that you should follow linux-kernel
- to track changes in API's. The final contact point for Linux 2.6+
- submissions is Andrew Morton.
-
-What Criteria Determine Acceptance
-----------------------------------
-
-Licensing:
- The code must be released to us under the
- GNU General Public License. If you wish the driver to be
- useful to other communities such as BSD you may release
- under multiple licenses. If you choose to release under
- licenses other than the GPL, you should include your
- rationale for your license choices in your cover letter.
- See accepted licenses at include/linux/module.h
-
-Copyright:
- The copyright owner must agree to use of GPL.
- It's best if the submitter and copyright owner
- are the same person/entity. If not, the name of
- the person/entity authorizing use of GPL should be
- listed in case it's necessary to verify the will of
- the copyright owner.
-
-Interfaces:
- If your driver uses existing interfaces and behaves like
- other drivers in the same class it will be much more likely
- to be accepted than if it invents gratuitous new ones.
- If you need to implement a common API over Linux and NT
- drivers do it in userspace.
-
-Code:
- Please use the Linux style of code formatting as documented
- in :ref:`Documentation/process/coding-style.rst <codingStyle>`.
- If you have sections of code
- that need to be in other formats, for example because they
- are shared with a windows driver kit and you want to
- maintain them just once separate them out nicely and note
- this fact.
-
-Portability:
- Pointers are not always 32bits, not all computers are little
- endian, people do not all have floating point and you
- shouldn't use inline x86 assembler in your driver without
- careful thought. Pure x86 drivers generally are not popular.
- If you only have x86 hardware it is hard to test portability
- but it is easy to make sure the code can easily be made
- portable.
-
-Clarity:
- It helps if anyone can see how to fix the driver. It helps
- you because you get patches not bug reports. If you submit a
- driver that intentionally obfuscates how the hardware works
- it will go in the bitbucket.
-
-PM support:
- Since Linux is used on many portable and desktop systems, your
- driver is likely to be used on such a system and therefore it
- should support basic power management by implementing, if
- necessary, the .suspend and .resume methods used during the
- system-wide suspend and resume transitions. You should verify
- that your driver correctly handles the suspend and resume, but
- if you are unable to ensure that, please at least define the
- .suspend method returning the -ENOSYS ("Function not
- implemented") error. You should also try to make sure that your
- driver uses as little power as possible when it's not doing
- anything. For the driver testing instructions see
- Documentation/power/drivers-testing.rst and for a relatively
- complete overview of the power management issues related to
- drivers see :ref:`Documentation/driver-api/pm/devices.rst <driverapi_pm_devices>`.
-
-Control:
- In general if there is active maintenance of a driver by
- the author then patches will be redirected to them unless
- they are totally obvious and without need of checking.
- If you want to be the contact and update point for the
- driver it is a good idea to state this in the comments,
- and include an entry in MAINTAINERS for your driver.
-
-What Criteria Do Not Determine Acceptance
------------------------------------------
-
-Vendor:
- Being the hardware vendor and maintaining the driver is
- often a good thing. If there is a stable working driver from
- other people already in the tree don't expect 'we are the
- vendor' to get your driver chosen. Ideally work with the
- existing driver author to build a single perfect driver.
-
-Author:
- It doesn't matter if a large Linux company wrote the driver,
- or you did. Nobody has any special access to the kernel
- tree. Anyone who tells you otherwise isn't telling the
- whole story.
-
-
-Resources
----------
-
-Linux kernel master tree:
- ftp.\ *country_code*\ .kernel.org:/pub/linux/kernel/...
-
- where *country_code* == your country code, such as
- **us**, **uk**, **fr**, etc.
-
- https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git
-
-Linux kernel mailing list:
- [email protected]
- [mail [email protected] to subscribe]
-
-Linux Device Drivers, Third Edition (covers 2.6.10):
- https://lwn.net/Kernel/LDD3/ (free version)
-
-LWN.net:
- Weekly summary of kernel development activity - https://lwn.net/
-
- 2.6 API changes:
-
- https://lwn.net/Articles/2.6-kernel-api/
-
- Porting drivers from prior kernels to 2.6:
-
- https://lwn.net/Articles/driver-porting/
-
-KernelNewbies:
- Documentation and assistance for new kernel programmers
-
- https://kernelnewbies.org/
-
-Linux USB project:
- http://www.linux-usb.org/
-
-How to NOT write kernel driver by Arjan van de Ven:
- https://landley.net/kdocs/ols/2002/ols2002-pages-545-555.pdf
-
-Kernel Janitor:
- https://kernelnewbies.org/KernelJanitors
-
-GIT, Fast Version Control System:
- https://git-scm.com/
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index a1cb6280fbcf..be49d8f2601b 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -12,9 +12,8 @@ This document contains a large number of suggestions in a relatively terse
format. For detailed information on how the kernel development process
works, see Documentation/process/development-process.rst. Also, read
Documentation/process/submit-checklist.rst
-for a list of items to check before submitting code. If you are submitting
-a driver, also read Documentation/process/submitting-drivers.rst; for device
-tree binding patches, read
+for a list of items to check before submitting code.
+For device tree binding patches, read
Documentation/devicetree/bindings/submitting-patches.rst.
This documentation assumes that you're using ``git`` to prepare your patches.
--
2.17.1
The original title comes from copying the content from a web page that
covered various mixed computer-science material. Within the kernel
documentation and its current structure, the title can be shortened.
Other titles considered, but not selected were:
- Index of More Kernel Documentation
- Further Kernel Documentation
- References to Further Kernel Documentation
Shorten the title.
Signed-off-by: Lukas Bulwahn <[email protected]>
---
Documentation/process/kernel-docs.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/process/kernel-docs.rst b/Documentation/process/kernel-docs.rst
index b4d98f6f797a..5d6fa71895cc 100644
--- a/Documentation/process/kernel-docs.rst
+++ b/Documentation/process/kernel-docs.rst
@@ -1,7 +1,7 @@
.. _kernel_docs:
-Index of Documentation for People Interested in Writing and/or Understanding the Linux Kernel
-=============================================================================================
+Index of Further Kernel Documentation
+=====================================
Juan-Mariano de Goyeneche <[email protected]>
--
2.17.1
Adjust the Taiwanese translation to the removal of submitting-drivers in
the English kernel documentation.
Signed-off-by: Lukas Bulwahn <[email protected]>
---
.../translations/zh_TW/process/5.Posting.rst | 3 +-
.../translations/zh_TW/process/howto.rst | 1 -
.../translations/zh_TW/process/index.rst | 1 -
.../zh_TW/process/submitting-drivers.rst | 164 ------------------
4 files changed, 1 insertion(+), 168 deletions(-)
delete mode 100644 Documentation/translations/zh_TW/process/submitting-drivers.rst
diff --git a/Documentation/translations/zh_TW/process/5.Posting.rst b/Documentation/translations/zh_TW/process/5.Posting.rst
index 5578bca403e6..280a8832ecc0 100644
--- a/Documentation/translations/zh_TW/process/5.Posting.rst
+++ b/Documentation/translations/zh_TW/process/5.Posting.rst
@@ -22,8 +22,7 @@
內核開發社區已經發展出一套用於發布補丁的約定和過程；遵循這些約定和過程將使
參與其中的每個人的生活更加輕鬆。本文檔試圖描述這些約定的部分細節；更多信息
也可在以下文檔中找到
-:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`，
-:ref:`Documentation/translations/zh_TW/process/submitting-drivers.rst <tw_submittingdrivers>`
+:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
和 :ref:`Documentation/translations/zh_TW/process/submit-checklist.rst <tw_submitchecklist>`。
何時郵寄
diff --git a/Documentation/translations/zh_TW/process/howto.rst b/Documentation/translations/zh_TW/process/howto.rst
index 2043691b92e3..68ae4411285b 100644
--- a/Documentation/translations/zh_TW/process/howto.rst
+++ b/Documentation/translations/zh_TW/process/howto.rst
@@ -99,7 +99,6 @@ Linux內核代碼中包含有大量的文檔。這些文檔對於學習如何與
的代碼。
:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
- :ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
這兩份文檔明確描述如何創建和發送補丁，其中包括（但不僅限於)：
- 郵件內容
diff --git a/Documentation/translations/zh_TW/process/index.rst b/Documentation/translations/zh_TW/process/index.rst
index ec7ad14bfd13..c5c59b4fd595 100644
--- a/Documentation/translations/zh_TW/process/index.rst
+++ b/Documentation/translations/zh_TW/process/index.rst
@@ -43,7 +43,6 @@
.. toctree::
:maxdepth: 1
- submitting-drivers
submit-checklist
stable-api-nonsense
stable-kernel-rules
diff --git a/Documentation/translations/zh_TW/process/submitting-drivers.rst b/Documentation/translations/zh_TW/process/submitting-drivers.rst
deleted file mode 100644
index 2fdd742318ba..000000000000
--- a/Documentation/translations/zh_TW/process/submitting-drivers.rst
+++ /dev/null
@@ -1,164 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0
-
-.. _tw_submittingdrivers:
-
-.. include:: ../disclaimer-zh_TW.rst
-
-:Original: :ref:`Documentation/process/submitting-drivers.rst
- <submittingdrivers>`
-
-如果想評論或更新本文的內容，請直接聯繫原文檔的維護者。如果你使用英文
-交流有困難的話，也可以向中文版維護者求助。如果本翻譯更新不及時或者翻
-譯存在問題，請聯繫中文版維護者::
-
- 中文版維護者： 李陽 Li Yang <[email protected]>
- 中文版翻譯者： 李陽 Li Yang <[email protected]>
- 中文版校譯者： 陳琦 Maggie Chen <[email protected]>
- 王聰 Wang Cong <[email protected]>
- 張巍 Zhang Wei <[email protected]>
- 胡皓文 Hu Haowen <[email protected]>
-
-如何向 Linux 內核提交驅動程序
-=============================
-
-這篇文檔將會解釋如何向不同的內核源碼樹提交設備驅動程序。請注意，如果你感
-興趣的是顯卡驅動程序，你也許應該訪問 XFree86 項目(https://www.xfree86.org/)
-和／或 X.org 項目 (https://x.org)。
-
-另請參閱 Documentation/translations/zh_TW/process/submitting-patches.rst 文檔。
-
-
-分配設備號
-----------
-
-塊設備和字符設備的主設備號與從設備號是由 Linux 命名編號分配權威 LANANA（
-現在是 Torben Mathiasen）負責分配。申請的網址是 https://www.lanana.org/。
-即使不準備提交到主流內核的設備驅動也需要在這裡分配設備號。有關詳細信息，
-請參閱 Documentation/admin-guide/devices.rst。
-
-如果你使用的不是已經分配的設備號，那麼當你提交設備驅動的時候，它將會被強
-制分配一個新的設備號，即便這個設備號和你之前發給客戶的截然不同。
-
-設備驅動的提交對象
-------------------
-
-Linux 2.0:
- 此內核源碼樹不接受新的驅動程序。
-
-Linux 2.2:
- 此內核源碼樹不接受新的驅動程序。
-
-Linux 2.4:
- 如果所屬的代碼領域在內核的 MAINTAINERS 文件中列有一個總維護者，
- 那麼請將驅動程序提交給他。如果此維護者沒有回應或者你找不到恰當的
- 維護者，那麼請聯繫 Willy Tarreau <[email protected]>。
-
-Linux 2.6:
- 除了遵循和 2.4 版內核同樣的規則外，你還需要在 linux-kernel 郵件
- 列表上跟蹤最新的 API 變化。向 Linux 2.6 內核提交驅動的頂級聯繫人
- 是 Andrew Morton <[email protected]>。
-
-決定設備驅動能否被接受的條件
-----------------------------
-
-許可： 代碼必須使用 GNU 通用公開許可證 (GPL) 提交給 Linux，但是
- 我們並不要求 GPL 是唯一的許可。你或許會希望同時使用多種
- 許可證發布，如果希望驅動程序可以被其他開源社區（比如BSD）
- 使用。請參考 include/linux/module.h 文件中所列出的可被
- 接受共存的許可。
-
-版權： 版權所有者必須同意使用 GPL 許可。最好提交者和版權所有者
- 是相同個人或實體。否則，必需列出授權使用 GPL 的版權所有
- 人或實體，以備驗證之需。
-
-接口： 如果你的驅動程序使用現成的接口並且和其他同類的驅動程序行
- 爲相似，而不是去發明無謂的新接口，那麼它將會更容易被接受。
- 如果你需要一個 Linux 和 NT 的通用驅動接口，那麼請在用
- 戶空間實現它。
-
-代碼： 請使用 Documentation/process/coding-style.rst 中所描述的 Linux 代碼風
- 格。如果你的某些代碼段（例如那些與 Windows 驅動程序包共
- 享的代碼段）需要使用其他格式，而你卻只希望維護一份代碼，
- 那麼請將它們很好地區分出來，並且註明原因。
-
-可移植性： 請注意，指針並不永遠是 32 位的，不是所有的計算機都使用小
- 尾模式 (little endian) 存儲數據，不是所有的人都擁有浮點
- 單元，不要隨便在你的驅動程序里嵌入 x86 彙編指令。只能在
- x86 上運行的驅動程序一般是不受歡迎的。雖然你可能只有 x86
- 硬體，很難測試驅動程序在其他平台上是否可用，但是確保代碼
- 可以被輕鬆地移植卻是很簡單的。
-
-清晰度： 做到所有人都能修補這個驅動程序將會很有好處，因爲這樣你將
- 會直接收到修復的補丁而不是 bug 報告。如果你提交一個試圖
- 隱藏硬體工作機理的驅動程序，那麼它將會被扔進廢紙簍。
-
-電源管理： 因爲 Linux 正在被很多行動裝置和桌面系統使用，所以你的驅
- 動程序也很有可能被使用在這些設備上。它應該支持最基本的電
- 源管理，即在需要的情況下實現系統級休眠和喚醒要用到的
- .suspend 和 .resume 函數。你應該檢查你的驅動程序是否能正
- 確地處理休眠與喚醒，如果實在無法確認，請至少把 .suspend
- 函數定義成返回 -ENOSYS（功能未實現）錯誤。你還應該嘗試確
- 保你的驅動在什麼都不乾的情況下將耗電降到最低。要獲得驅動
- 程序測試的指導，請參閱
- Documentation/power/drivers-testing.rst。有關驅動程序電
- 源管理問題相對全面的概述，請參閱
- Documentation/driver-api/pm/devices.rst。
-
-管理： 如果一個驅動程序的作者還在進行有效的維護，那麼通常除了那
- 些明顯正確且不需要任何檢查的補丁以外，其他所有的補丁都會
- 被轉發給作者。如果你希望成爲驅動程序的聯繫人和更新者，最
- 好在代碼注釋中寫明並且在 MAINTAINERS 文件中加入這個驅動
- 程序的條目。
-
-不影響設備驅動能否被接受的條件
-------------------------------
-
-供應商： 由硬體供應商來維護驅動程序通常是一件好事。不過，如果源碼
- 樹里已經有其他人提供了可穩定工作的驅動程序，那麼請不要期
- 望「我是供應商」會成爲內核改用你的驅動程序的理由。理想的情
- 況是：供應商與現有驅動程序的作者合作，構建一個統一完美的
- 驅動程序。
-
-作者： 驅動程序是由大的 Linux 公司研發還是由你個人編寫，並不影
- 響其是否能被內核接受。沒有人對內核源碼樹享有特權。只要你
- 充分了解內核社區，你就會發現這一點。
-
-
-資源列表
---------
-
-Linux 內核主源碼樹：
- ftp.??.kernel.org:/pub/linux/kernel/...
- ?? == 你的國家代碼，例如 "cn"、"us"、"uk"、"fr" 等等
-
-Linux 內核郵件列表：
- [email protected]
- [可通過向[email protected]發郵件來訂閱]
-
-Linux 設備驅動程序，第三版（探討 2.6.10 版內核）：
- https://lwn.net/Kernel/LDD3/ （免費版）
-
-LWN.net:
- 每周內核開發活動摘要 - https://lwn.net/
-
- 2.6 版中 API 的變更：
-
- https://lwn.net/Articles/2.6-kernel-api/
-
- 將舊版內核的驅動程序移植到 2.6 版：
-
- https://lwn.net/Articles/driver-porting/
-
-內核新手(KernelNewbies):
- 爲新的內核開發者提供文檔和幫助
- https://kernelnewbies.org/
-
-Linux USB項目：
- http://www.linux-usb.org/
-
-寫內核驅動的「不要」（Arjan van de Ven著）:
- http://www.fenrus.org/how-to-not-write-a-device-driver-paper.pdf
-
-內核清潔工 (Kernel Janitor):
- https://kernelnewbies.org/KernelJanitors
-
--
2.17.1
Lukas Bulwahn <[email protected]> writes:
> Dear Jonathan, dear Federico, dear Alex, dear Yanteng, dear Hu,
>
> Here is an attempt to delete submitting-drivers with some improvements
> and clean-up in other documentation places to convince ourselves that
> nothing valuable is lost when deleting this checklist.
So my purpose today was to go ahead and apply these patches, but ...
> Patch 1, 2 and 3 is just basic clean-up before adding a new reference (see
> Patch 4). Patch 4 adds the one reference from submitting-drivers, not
> already mentioned elsewhere in the repository. Patch 5 updates a confusing
> statement in devices.rst from earlier .txt/.tex distinction times to the
> new state now with Sphinx & .rst.
>
> Patch 6 finally deletes the outdated document, with a cross-check what is
> covered elsewhere and few open questions (see below).
>
> Patch 7 and 8 have been reworked with the native-speaking doc maintainers;
> they cause no new warnings and are ready to pick,
>
> Patch 9 to 11 are weak attempts to adjust the translation, but they need
> to be taken further by others due to my lack of knowledge on the other
> languages. They would currently also cause new warnings in the doc-build
> right now. They should not be picked if there is no one to continue
> to adjust the text and fix the warnings on broken references.
>
> I hope that patches 1 to 8 can be picked into doc-next, and then we see
> how to fix up the translations as well.
...even if I do that I get warnings:
Documentation/translations/zh_CN/process/howto.rst:98: WARNING:
undefined label: submittingdrivers (if the link has no caption the
label must precede a section header)
it's actually better if I apply the full series, but there's still a few
of them. I *really* don't want to add more warnings to the docs build,
so I've backed off for now.
Alex, can you fix the remaining references in zh_CN?
For zh_TW I'm wondering ... that is increasingly looking like an
unmaintained drive-by submission. I suppose we can just brute-force
remove the references, but I once again find myself wondering about the
value of this translation. Is there anybody out there who cares about
it who could fix this up properly?
Thanks,
jon
> Alex, can you fix the remaining references in zh_CN?
>
> For zh_TW I'm wondering ... that is increasingly looking like an
> unmaintained drive-by submission. I suppose we can just brute-force
> remove the references, but I once again find myself wondering about the
> value of this translation. Is there anybody out there who cares about
> it who could fix this up properly?
Hi Jon,
Both zh_CN and zh_TW were fixed on
https://lore.kernel.org/linux-doc/[email protected]/T/#u
Sorry for the issue
Thanks
Alex
Alex Shi <[email protected]> writes:
>> Alex, can you fix the remaining references in zh_CN?
>>
>> For zh_TW I'm wondering ... that is increasingly looking like an
>> unmaintained drive-by submission. I suppose we can just brute-force
>> remove the references, but I once again find myself wondering about the
>> value of this translation. Is there anybody out there who cares about
>> it who could fix this up properly?
>
> Hi Jon,
>
> Both zh_CN and zh_TW were fixed on
> https://lore.kernel.org/linux-doc/[email protected]/T/#u
>
> Sorry for the issue
No worries, thanks for dealing with it. That did the trick, and the
series is now applied.
Thanks,
jon