Merge branch 'submitting-drivers-removal' into docs-next
Lukas Bulwahn says: 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. Additionally, this branch includes a translation fix from Alex Shi.
This commit is contained in:
Jonathan Corbet
Коммит
bb6279d8ed
|
|
@ -7,10 +7,9 @@ This list is the Linux Device List, the official registry of allocated
|
|||
device numbers and ``/dev`` directory nodes for the Linux operating
|
||||
system.
|
||||
|
||||
The LaTeX version of this document is no longer maintained, nor is
|
||||
the document that used to reside at lanana.org. This version in the
|
||||
mainline Linux kernel is the master document. Updates shall be sent
|
||||
as patches to the kernel maintainers (see the
|
||||
The version of this document at lanana.org is no longer maintained. This
|
||||
version in the mainline Linux kernel is the master document. Updates
|
||||
shall be sent as patches to the kernel maintainers (see the
|
||||
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>` document).
|
||||
Specifically explore the sections titled "CHAR and MISC DRIVERS", and
|
||||
"BLOCK LAYER" in the MAINTAINERS file to find the right maintainers
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
===============
|
||||
|
|
|
|||
|
|
@ -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>`.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -1,9 +1,10 @@
|
|||
.. _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 <jmseyas@dit.upm.es>
|
||||
Initial Author: Juan-Mariano de Goyeneche (<jmseyas@dit.upm.es>;
|
||||
email address is defunct now.)
|
||||
|
||||
The need for a document like this one became apparent in the
|
||||
linux-kernel mailing list as the same questions, asking for pointers
|
||||
|
|
@ -16,21 +17,16 @@ philosophy and design decisions behind this code.
|
|||
|
||||
Unfortunately, not many documents are available for beginners to
|
||||
start. And, even if they exist, there was no "well-known" place which
|
||||
kept track of them. These lines try to cover this lack. All documents
|
||||
available on line known by the author are listed, while some reference
|
||||
books are also mentioned.
|
||||
kept track of them. These lines try to cover this lack.
|
||||
|
||||
PLEASE, if you know any paper not listed here or write a new document,
|
||||
send me an e-mail, and I'll include a reference to it here. Any
|
||||
corrections, ideas or comments are also welcomed.
|
||||
include a reference to it here, following the kernel's patch submission
|
||||
process. Any corrections, ideas or comments are also welcome.
|
||||
|
||||
The papers that follow are listed in no particular order. All are
|
||||
cataloged with the following fields: the document's "Title", the
|
||||
"Author"/s, the "URL" where they can be found, some "Keywords" helpful
|
||||
when searching for specific topics, and a brief "Description" of the
|
||||
Document.
|
||||
|
||||
Enjoy!
|
||||
All documents are cataloged with the following fields: the document's
|
||||
"Title", the "Author"/s, the "URL" where they can be found, some
|
||||
"Keywords" helpful when searching for specific topics, and a brief
|
||||
"Description" of the Document.
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
@ -83,6 +79,18 @@ On-line docs
|
|||
Finally this trace-log is used as base for more a exact conceptual
|
||||
exploration and description of the Linux TCP/IP implementation.*
|
||||
|
||||
* Title: **The Linux Kernel Module Programming Guide**
|
||||
|
||||
:Author: Peter Jay Salzman, Michael Burian, Ori Pomerantz, Bob Mottram,
|
||||
Jim Huang.
|
||||
:URL: https://sysprog21.github.io/lkmpg/
|
||||
:Date: 2021
|
||||
:Keywords: modules, GPL book, /proc, ioctls, system calls,
|
||||
interrupt handlers .
|
||||
:Description: A very nice GPL book on the topic of modules
|
||||
programming. Lots of examples. Currently the new version is being
|
||||
actively maintained at https://github.com/sysprog21/lkmpg.
|
||||
|
||||
* Title: **On submitting kernel Patches**
|
||||
|
||||
:Author: Andi Kleen
|
||||
|
|
@ -126,17 +134,19 @@ On-line docs
|
|||
describes how to write user-mode utilities for communicating with
|
||||
Card Services.
|
||||
|
||||
* Title: **The Linux Kernel Module Programming Guide**
|
||||
* Title: **How NOT to write kernel drivers**
|
||||
|
||||
:Author: Peter Jay Salzman, Michael Burian, Ori Pomerantz, Bob Mottram,
|
||||
Jim Huang.
|
||||
:URL: https://sysprog21.github.io/lkmpg/
|
||||
:Date: 2021
|
||||
:Keywords: modules, GPL book, /proc, ioctls, system calls,
|
||||
interrupt handlers .
|
||||
:Description: A very nice GPL book on the topic of modules
|
||||
programming. Lots of examples. Currently the new version is being
|
||||
actively maintained at https://github.com/sysprog21/lkmpg.
|
||||
:Author: Arjan van de Ven.
|
||||
:URL: https://landley.net/kdocs/ols/2002/ols2002-pages-545-555.pdf
|
||||
:Date: 2002
|
||||
:Keywords: driver.
|
||||
:Description: Programming bugs and Do-nots in kernel driver development
|
||||
:Abstract: *Quit a few tutorials, articles and books give an introduction
|
||||
on how to write Linux kernel drivers. Unfortunately the things one
|
||||
should NOT do in Linux kernel code is either only a minor appendix
|
||||
or, more commonly, completely absent. This paper tries to briefly touch
|
||||
the areas in which the most common and serious bugs and do-nots are
|
||||
encountered.*
|
||||
|
||||
* Title: **Global spinlock list and usage**
|
||||
|
||||
|
|
|
|||
|
|
@ -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 <w@1wt.eu>.
|
||||
|
||||
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:
|
||||
linux-kernel@vger.kernel.org
|
||||
[mail majordomo@vger.kernel.org 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/
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -795,8 +795,7 @@ anche per avere patch pulite, c'è del lavoro amministrativo da fare:
|
|||
di un semplice impegno su una parte del codice.
|
||||
|
||||
- Infine, non dimenticatevi di leggere
|
||||
``Documentation/process/submitting-patches.rst`` e possibilmente anche
|
||||
``Documentation/process/submitting-drivers.rst``.
|
||||
``Documentation/process/submitting-patches.rst``.
|
||||
|
||||
Trucchetti del kernel
|
||||
=====================
|
||||
|
|
|
|||
|
|
@ -16,9 +16,8 @@ e di procedure per la pubblicazione delle patch; seguirle renderà la vita
|
|||
più facile a tutti quanti. Questo documento cercherà di coprire questi
|
||||
argomenti con un ragionevole livello di dettaglio; più informazioni possono
|
||||
essere trovare nella cartella 'Documentation', nei file
|
||||
:ref:`translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`,
|
||||
:ref:`translations/it_IT/process/submitting-drivers.rst <it_submittingdrivers>`, e
|
||||
:ref:`translations/it_IT/process/submit-checklist.rst <it_submitchecklist>`.
|
||||
:ref:`translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
|
||||
e :ref:`translations/it_IT/process/submit-checklist.rst <it_submitchecklist>`.
|
||||
|
||||
|
||||
Quando pubblicarle
|
||||
|
|
|
|||
|
|
@ -13,9 +13,8 @@ e argomenti correlati. Primo tra questi sarà sempre la cartella Documentation
|
|||
che si trova nei sorgenti kernel.
|
||||
|
||||
Il file :ref:`process/howto.rst <it_process_howto>` è un punto di partenza
|
||||
importante; :ref:`process/submitting-patches.rst <it_submittingpatches>` e
|
||||
:ref:`process/submitting-drivers.rst <it_submittingdrivers>` sono
|
||||
anch'essi qualcosa che tutti gli sviluppatori del kernel dovrebbero leggere.
|
||||
importante; :ref:`process/submitting-patches.rst <it_submittingpatches>` è
|
||||
anch'esso qualcosa che tutti gli sviluppatori del kernel dovrebbero leggere.
|
||||
Molte API interne al kernel sono documentate utilizzando il meccanismo
|
||||
kerneldoc; "make htmldocs" o "make pdfdocs" possono essere usati per generare
|
||||
quei documenti in HTML o PDF (sebbene le versioni di TeX di alcune
|
||||
|
|
|
|||
|
|
@ -109,8 +109,7 @@ Di seguito una lista di file che sono presenti nei sorgente del kernel e che
|
|||
accetteranno patch solo se queste osserveranno tali regole, e molte
|
||||
persone revisioneranno il codice solo se scritto nello stile appropriato.
|
||||
|
||||
:ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>` e
|
||||
:ref:`Documentation/translations/it_IT/process/submitting-drivers.rst <it_submittingdrivers>`
|
||||
:ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
|
||||
|
||||
Questo file descrive dettagliatamente come creare ed inviare una patch
|
||||
con successo, includendo (ma non solo questo):
|
||||
|
|
|
|||
|
|
@ -41,7 +41,6 @@ degli sviluppatori:
|
|||
:maxdepth: 1
|
||||
|
||||
changes
|
||||
submitting-drivers
|
||||
stable-api-nonsense
|
||||
management-style
|
||||
stable-kernel-rules
|
||||
|
|
|
|||
|
|
@ -1,16 +0,0 @@
|
|||
.. include:: ../disclaimer-ita.rst
|
||||
|
||||
:Original: :ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
|
||||
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>
|
||||
|
||||
.. _it_submittingdrivers:
|
||||
|
||||
Sottomettere driver per il kernel Linux
|
||||
=======================================
|
||||
|
||||
.. note::
|
||||
|
||||
Questo documento è vecchio e negli ultimi anni non è stato più aggiornato;
|
||||
dovrebbe essere aggiornato, o forse meglio, rimosso. La maggior parte di
|
||||
quello che viene detto qui può essere trovato anche negli altri documenti
|
||||
dedicati allo sviluppo. Per questo motivo il documento non verrà tradotto.
|
||||
|
|
@ -18,10 +18,8 @@ Questo documento contiene un vasto numero di suggerimenti concisi. Per maggiori
|
|||
dettagli su come funziona il processo di sviluppo del kernel leggete
|
||||
Documentation/translations/it_IT/process/development-process.rst. Leggete anche
|
||||
Documentation/translations/it_IT/process/submit-checklist.rst per una lista di
|
||||
punti da verificare prima di inviare del codice. Se state inviando un driver,
|
||||
allora leggete anche
|
||||
Documentation/translations/it_IT/process/submitting-drivers.rst; per delle patch
|
||||
relative alle associazioni per Device Tree leggete
|
||||
punti da verificare prima di inviare del codice.
|
||||
Per delle patch relative alle associazioni per Device Tree leggete
|
||||
Documentation/translations/it_IT/process/submitting-patches.rst.
|
||||
|
||||
Questa documentazione assume che sappiate usare ``git`` per preparare le patch.
|
||||
|
|
|
|||
|
|
@ -129,8 +129,8 @@ linux-api@vger.kernel.org に送ることを勧めます。
|
|||
ルに従っているものだけを受け付け、多くの人は正しいスタイルのコード
|
||||
だけをレビューします。
|
||||
|
||||
:ref:`Documentation/process/submitting-patches.rst <codingstyle>` と :ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
|
||||
これらのファイルには、どうやってうまくパッチを作って投稿するかにつ
|
||||
:ref:`Documentation/process/submitting-patches.rst <codingstyle>`
|
||||
このファイルには、どうやってうまくパッチを作って投稿するかにつ
|
||||
いて非常に詳しく書かれており、以下を含みます (これだけに限らない
|
||||
けれども)
|
||||
|
||||
|
|
|
|||
|
|
@ -124,7 +124,7 @@ mtk.manpages@gmail.com의 메인테이너에게 보낼 것을 권장한다.
|
|||
메인테이너들은 이 규칙을 따르는 패치들만을 받아들일 것이고 많은 사람들이
|
||||
그 패치가 올바른 스타일일 경우만 코드를 검토할 것이다.
|
||||
|
||||
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>` 와 :ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
|
||||
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
|
||||
이 파일들은 성공적으로 패치를 만들고 보내는 법을 다음의 내용들로
|
||||
굉장히 상세히 설명하고 있다(그러나 다음으로 한정되진 않는다).
|
||||
|
||||
|
|
|
|||
|
|
@ -633,8 +633,7 @@ C++
|
|||
意味着您希望在对子系统进行更改时得到询问，并了解缺陷；这意味着对某部分
|
||||
代码做出更多承诺。
|
||||
|
||||
- 最后，别忘记去阅读 Documentation/process/submitting-patches.rst ，
|
||||
也许还有 Documentation/process/submitting-drivers.rst 。
|
||||
- 最后，别忘记去阅读 Documentation/process/submitting-patches.rst。
|
||||
|
||||
Kernel 仙女棒
|
||||
===============
|
||||
|
|
|
|||
|
|
@ -19,8 +19,7 @@
|
|||
内核开发社区已经发展出一套用于发布补丁的约定和过程；遵循这些约定和过程将使
|
||||
参与其中的每个人的生活更加轻松。本文档试图描述这些约定的部分细节；更多信息
|
||||
也可在以下文档中找到
|
||||
:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`，
|
||||
:ref:`Documentation/translations/zh_CN/process/submitting-drivers.rst <cn_submittingdrivers>`
|
||||
:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
|
||||
和 :ref:`Documentation/translations/zh_CN/process/submit-checklist.rst <cn_submitchecklist>`。
|
||||
|
||||
何时寄送
|
||||
|
|
|
|||
|
|
@ -19,7 +19,6 @@
|
|||
:ref:`Documentation/translations/zh_CN/process/howto.rst <cn_process_howto>`
|
||||
文件是一个重要的起点；
|
||||
:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
|
||||
和 :ref:`Documentation/translations/zh_CN/process/submitting-drivers.rst <cn_submittingdrivers>`
|
||||
也是所有内核开发人员都应该阅读的内容。许多内部内核API都是使用kerneldoc机制
|
||||
记录的；“make htmldocs”或“make pdfdocs”可用于以HTML或PDF格式生成这些文档
|
||||
（尽管某些发行版提供的tex版本会遇到内部限制，无法正确处理文档）。
|
||||
|
|
|
|||
|
|
@ -96,7 +96,6 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与
|
|||
的代码。
|
||||
|
||||
:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <cn_submittingpatches>`
|
||||
:ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
|
||||
|
||||
这两份文档明确描述如何创建和发送补丁，其中包括（但不仅限于)：
|
||||
- 邮件内容
|
||||
|
|
|
|||
|
|
@ -40,7 +40,6 @@
|
|||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
submitting-drivers
|
||||
submit-checklist
|
||||
stable-api-nonsense
|
||||
stable-kernel-rules
|
||||
|
|
|
|||
|
|
@ -1,160 +0,0 @@
|
|||
.. _cn_submittingdrivers:
|
||||
|
||||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: :ref:`Documentation/process/submitting-drivers.rst
|
||||
<submittingdrivers>`
|
||||
|
||||
如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
|
||||
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
|
||||
译存在问题，请联系中文版维护者::
|
||||
|
||||
中文版维护者： 李阳 Li Yang <leoyang.li@nxp.com>
|
||||
中文版翻译者： 李阳 Li Yang <leoyang.li@nxp.com>
|
||||
中文版校译者： 陈琦 Maggie Chen <chenqi@beyondsoft.com>
|
||||
王聪 Wang Cong <xiyou.wangcong@gmail.com>
|
||||
张巍 Zhang Wei <wezhang@outlook.com>
|
||||
|
||||
如何向 Linux 内核提交驱动程序
|
||||
=============================
|
||||
|
||||
这篇文档将会解释如何向不同的内核源码树提交设备驱动程序。请注意，如果你感
|
||||
兴趣的是显卡驱动程序，你也许应该访问 XFree86 项目(https://www.xfree86.org/)
|
||||
和／或 X.org 项目 (https://x.org)。
|
||||
|
||||
另请参阅 Documentation/translations/zh_CN/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 <w@1wt.eu>。
|
||||
|
||||
Linux 2.6:
|
||||
除了遵循和 2.4 版内核同样的规则外，你还需要在 linux-kernel 邮件
|
||||
列表上跟踪最新的 API 变化。向 Linux 2.6 内核提交驱动的顶级联系人
|
||||
是 Andrew Morton <akpm@linux-foundation.org>。
|
||||
|
||||
决定设备驱动能否被接受的条件
|
||||
----------------------------
|
||||
|
||||
许可： 代码必须使用 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 内核邮件列表：
|
||||
linux-kernel@vger.kernel.org
|
||||
[可通过向majordomo@vger.kernel.org发邮件来订阅]
|
||||
|
||||
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
|
||||
|
|
@ -23,9 +23,7 @@
|
|||
以下文档含有大量简洁的建议， 具体请见：
|
||||
:ref:`Documentation/process <development_process_main>`
|
||||
同样，:ref:`Documentation/translations/zh_CN/process/submit-checklist.rst <cn_submitchecklist>`
|
||||
给出在提交代码前需要检查的项目的列表。如果你在提交一个驱动程序，那么
|
||||
同时阅读一下:
|
||||
:ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
|
||||
给出在提交代码前需要检查的项目的列表。
|
||||
|
||||
其中许多步骤描述了Git版本控制系统的默认行为；如果您使用Git来准备补丁，
|
||||
您将发现它为您完成的大部分机械工作，尽管您仍然需要准备和记录一组合理的
|
||||
|
|
|
|||
|
|
@ -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>`。
|
||||
|
||||
何時郵寄
|
||||
|
|
|
|||
|
|
@ -22,7 +22,6 @@
|
|||
:ref:`Documentation/translations/zh_TW/process/howto.rst <tw_process_howto>`
|
||||
文件是一個重要的起點；
|
||||
:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
|
||||
和 :ref:`Documentation/translations/zh_TW/process/submitting-drivers.rst <tw_submittingdrivers>`
|
||||
也是所有內核開發人員都應該閱讀的內容。許多內部內核API都是使用kerneldoc機制
|
||||
記錄的；「make htmldocs」或「make pdfdocs」可用於以HTML或PDF格式生成這些文檔
|
||||
（儘管某些發行版提供的tex版本會遇到內部限制，無法正確處理文檔）。
|
||||
|
|
|
|||
|
|
@ -99,7 +99,6 @@ Linux內核代碼中包含有大量的文檔。這些文檔對於學習如何與
|
|||
的代碼。
|
||||
|
||||
:ref:`Documentation/translations/zh_TW/process/submitting-patches.rst <tw_submittingpatches>`
|
||||
:ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
|
||||
|
||||
這兩份文檔明確描述如何創建和發送補丁，其中包括（但不僅限於)：
|
||||
- 郵件內容
|
||||
|
|
|
|||
|
|
@ -43,7 +43,6 @@
|
|||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
submitting-drivers
|
||||
submit-checklist
|
||||
stable-api-nonsense
|
||||
stable-kernel-rules
|
||||
|
|
|
|||
|
|
@ -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 <leoyang.li@nxp.com>
|
||||
中文版翻譯者： 李陽 Li Yang <leoyang.li@nxp.com>
|
||||
中文版校譯者： 陳琦 Maggie Chen <chenqi@beyondsoft.com>
|
||||
王聰 Wang Cong <xiyou.wangcong@gmail.com>
|
||||
張巍 Zhang Wei <wezhang@outlook.com>
|
||||
胡皓文 Hu Haowen <src.res@email.cn>
|
||||
|
||||
如何向 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 <w@1wt.eu>。
|
||||
|
||||
Linux 2.6:
|
||||
除了遵循和 2.4 版內核同樣的規則外，你還需要在 linux-kernel 郵件
|
||||
列表上跟蹤最新的 API 變化。向 Linux 2.6 內核提交驅動的頂級聯繫人
|
||||
是 Andrew Morton <akpm@linux-foundation.org>。
|
||||
|
||||
決定設備驅動能否被接受的條件
|
||||
----------------------------
|
||||
|
||||
許可： 代碼必須使用 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 內核郵件列表：
|
||||
linux-kernel@vger.kernel.org
|
||||
[可通過向majordomo@vger.kernel.org發郵件來訂閱]
|
||||
|
||||
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
|
||||
|
||||
|
|
@ -26,9 +26,7 @@
|
|||
以下文檔含有大量簡潔的建議， 具體請見：
|
||||
:ref:`Documentation/process <development_process_main>`
|
||||
同樣，:ref:`Documentation/translations/zh_TW/process/submit-checklist.rst <tw_submitchecklist>`
|
||||
給出在提交代碼前需要檢查的項目的列表。如果你在提交一個驅動程序，那麼
|
||||
同時閱讀一下:
|
||||
:ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
|
||||
給出在提交代碼前需要檢查的項目的列表。
|
||||
|
||||
其中許多步驟描述了Git版本控制系統的默認行爲；如果您使用Git來準備補丁，
|
||||
您將發現它爲您完成的大部分機械工作，儘管您仍然需要準備和記錄一組合理的
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче