From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: Linux Doc Mailing List <linux-doc@vger.kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>,
Mauro Carvalho Chehab <mchehab@infradead.org>,
Markus Heiser <markus.heiser@darmarit.de>,
Jonathan Corbet <corbet@lwn.net>,
Jani Nikula <jani.nikula@linux.intel.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: [PATCH v3 04/21] Documentation/HOWTO: convert to ReST notation
Date: Wed, 14 Sep 2016 08:06:33 -0300 [thread overview]
Message-ID: <db76cc67bf1aa61345f226762b67532deb939ed1.1473849886.git.mchehab@s-opensource.com> (raw)
In-Reply-To: <cover.1473849886.git.mchehab@s-opensource.com>
In-Reply-To: <cover.1473849886.git.mchehab@s-opensource.com>
This document is almost compliant with ReST notation, but some
small adjustments are needed to make it parse properly by
Sphinx (mostly, add blank lines where needed).
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
---
Documentation/HOWTO | 53 +++++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 49 insertions(+), 4 deletions(-)
diff --git a/Documentation/HOWTO b/Documentation/HOWTO
index 1f345da28ec5..5a85e3a8112b 100644
--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -1,5 +1,5 @@
HOWTO do Linux kernel development
----------------------------------
+=================================
This is the be-all, end-all document on this topic. It contains
instructions on how to become a Linux kernel developer and how to learn
@@ -28,6 +28,7 @@ kernel development. Assembly (any architecture) is not required unless
you plan to do low-level development for that architecture. Though they
are not a good substitute for a solid C education and/or years of
experience, the following books are good for, if anything, reference:
+
- "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
- "Practical C Programming" by Steve Oualline [O'Reilly]
- "C: A Reference Manual" by Harbison and Steele [Prentice Hall]
@@ -64,6 +65,7 @@ people on the mailing lists are not lawyers, and you should not rely on
their statements on legal matters.
For common questions and answers about the GPL, please see:
+
http://www.gnu.org/licenses/gpl-faq.html
@@ -82,6 +84,7 @@ linux-api@vger.kernel.org.
Here is a list of files that are in the kernel source tree that are
required reading:
+
README
This file gives a short background on the Linux kernel and describes
what is necessary to do to configure and build the kernel. People
@@ -99,30 +102,37 @@ required reading:
patches if these rules are followed, and many people will only
review code if it is in the proper style.
- Documentation/SubmittingPatches
- Documentation/SubmittingDrivers
+ Documentation/SubmittingPatches and Documentation/SubmittingDrivers
These files describe in explicit detail how to successfully create
and send a patch, including (but not limited to):
+
- Email contents
- Email format
- Who to send it to
+
Following these rules will not guarantee success (as all patches are
subject to scrutiny for content and style), but not following them
will almost always prevent it.
Other excellent descriptions of how to create patches properly are:
+
"The Perfect Patch"
+
http://www.ozlabs.org/~akpm/stuff/tpp.txt
+
"Linux kernel patch submission format"
+
http://linux.yyz.us/patch-format.html
Documentation/stable_api_nonsense.txt
This file describes the rationale behind the conscious decision to
not have a stable API within the kernel, including things like:
+
- Subsystem shim-layers (for compatibility?)
- Driver portability between Operating Systems.
- Mitigating rapid change within the kernel source tree (or
preventing rapid change)
+
This document is crucial for understanding the Linux development
philosophy and is very important for people moving to Linux from
development on other Operating Systems.
@@ -159,10 +169,14 @@ full description of the in-kernel API, and rules on how to handle
locking properly. The documents will be created in the
Documentation/DocBook/ directory and can be generated as PDF,
Postscript, HTML, and man pages by running:
+
+::
+
make pdfdocs
make psdocs
make htmldocs
make mandocs
+
respectively from the main kernel source directory.
@@ -171,7 +185,9 @@ Becoming A Kernel Developer
If you do not know anything about Linux kernel development, you should
look at the Linux KernelNewbies project:
+
http://kernelnewbies.org
+
It consists of a helpful mailing list where you can ask almost any type
of basic kernel development question (make sure to search the archives
first, before asking something that has already been answered in the
@@ -187,7 +203,9 @@ apply a patch.
If you do not know where you want to start, but you want to look for
some task to start doing to join into the kernel development community,
go to the Linux Kernel Janitor's project:
+
http://kernelnewbies.org/KernelJanitors
+
It is a great place to start. It describes a list of relatively simple
problems that need to be cleaned up and fixed within the Linux kernel
source tree. Working with the developers in charge of this project, you
@@ -199,6 +217,7 @@ If you already have a chunk of code that you want to put into the kernel
tree, but need some help getting it in the proper form, the
kernel-mentors project was created to help you out with this. It is a
mailing list, and can be found at:
+
http://selenic.com/mailman/listinfo/kernel-mentors
Before making any actual modifications to the Linux kernel code, it is
@@ -209,6 +228,7 @@ tools. One such tool that is particularly recommended is the Linux
Cross-Reference project, which is able to present source code in a
self-referential, indexed webpage format. An excellent up-to-date
repository of the kernel code may be found at:
+
http://lxr.free-electrons.com/
@@ -218,6 +238,7 @@ The development process
Linux kernel development process currently consists of a few different
main kernel "branches" and lots of different subsystem-specific kernel
branches. These different branches are:
+
- main 4.x kernel tree
- 4.x.y -stable kernel tree
- 4.x -git kernel patches
@@ -229,6 +250,7 @@ branches. These different branches are:
4.x kernels are maintained by Linus Torvalds, and can be found on
kernel.org in the pub/linux/kernel/v4.x/ directory. Its development
process is as follows:
+
- As soon as a new kernel is released a two weeks window is open,
during this period of time maintainers can submit big diffs to
Linus, usually the patches that have already been included in the
@@ -253,6 +275,9 @@ process is as follows:
It is worth mentioning what Andrew Morton wrote on the linux-kernel
mailing list about kernel releases:
+
+::
+
"Nobody knows when a kernel will be released, because it's
released according to perceived bug status, not according to a
preconceived timeline."
@@ -318,6 +343,7 @@ Before updates from subsystem trees are merged into the mainline 4.x
tree, they need to be integration-tested. For this purpose, a special
testing repository exists into which virtually all subsystem trees are
pulled on an almost daily basis:
+
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
This way, the -next kernel gives a summary outlook onto what will be
@@ -331,6 +357,7 @@ Bug Reporting
bugzilla.kernel.org is where the Linux kernel developers track kernel
bugs. Users are encouraged to report all bugs that they find in this
tool. For details on how to use the kernel bugzilla, please see:
+
http://bugzilla.kernel.org/page.cgi?id=faq.html
The file REPORTING-BUGS in the main kernel source directory has a good
@@ -365,10 +392,14 @@ Mailing lists
As some of the above documents describe, the majority of the core kernel
developers participate on the Linux Kernel Mailing list. Details on how
to subscribe and unsubscribe from the list can be found at:
+
http://vger.kernel.org/vger-lists.html#linux-kernel
+
There are archives of the mailing list on the web in many different
places. Use a search engine to find these archives. For example:
+
http://dir.gmane.org/gmane.linux.kernel
+
It is highly recommended that you search the archives about the topic
you want to bring up, before you post it to the list. A lot of things
already discussed in detail are only recorded at the mailing list
@@ -381,11 +412,13 @@ groups.
Many of the lists are hosted on kernel.org. Information on them can be
found at:
+
http://vger.kernel.org/vger-lists.html
Please remember to follow good behavioral habits when using the lists.
Though a bit cheesy, the following URL has some simple guidelines for
interacting with the list (or any list):
+
http://www.albion.com/netiquette/
If multiple people respond to your mail, the CC: list of recipients may
@@ -418,6 +451,7 @@ The goal of the kernel community is to provide the best possible kernel
there is. When you submit a patch for acceptance, it will be reviewed
on its technical merits and those alone. So, what should you be
expecting?
+
- criticism
- comments
- requests for change
@@ -432,6 +466,7 @@ If there are no responses to your posting, wait a few days and try
again, sometimes things get lost in the huge volume.
What should you not do?
+
- expect your patch to be accepted without question
- become defensive
- ignore comments
@@ -457,7 +492,9 @@ Differences between the kernel community and corporate structures
The kernel community works differently than most traditional corporate
development environments. Here are a list of things that you can try to
do to avoid problems:
+
Good things to say regarding your proposed changes:
+
- "This solves multiple problems."
- "This deletes 2000 lines of code."
- "Here is a patch that explains what I am trying to describe."
@@ -466,6 +503,7 @@ do to avoid problems:
- "This increases performance on typical machines..."
Bad things you should avoid saying:
+
- "We did it this way in AIX/ptx/Solaris, so therefore it must be
good..."
- "I've being doing this for 20 years, so..."
@@ -527,12 +565,15 @@ The reasons for breaking things up are the following:
and simplify (or simply re-order) patches before submitting them.
Here is an analogy from kernel developer Al Viro:
+
+::
+
"Think of a teacher grading homework from a math student. The
teacher does not want to see the student's trials and errors
before they came up with the solution. They want to see the
cleanest, most elegant answer. A good student knows this, and
would never submit her intermediate work before the final
- solution."
+ solution.
The same is true of kernel development. The maintainers and
reviewers do not want to see the thought process behind the
@@ -565,6 +606,7 @@ When sending in your patches, pay special attention to what you say in
the text in your email. This information will become the ChangeLog
information for the patch, and will be preserved for everyone to see for
all time. It should describe the patch completely, containing:
+
- why the change is necessary
- the overall design approach in the patch
- implementation details
@@ -572,7 +614,9 @@ all time. It should describe the patch completely, containing:
For more details on what this should all look like, please see the
ChangeLog section of the document:
+
"The Perfect Patch"
+
http://www.ozlabs.org/~akpm/stuff/tpp.txt
@@ -588,6 +632,7 @@ start exactly where you are now.
----------
+
Thanks to Paolo Ciarrocchi who allowed the "Development Process"
(http://lwn.net/Articles/94386/) section
to be based on text he had written, and to Randy Dunlap and Gerrit
--
2.7.4
next prev parent reply other threads:[~2016-09-14 11:13 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-14 11:06 [PATCH v3 00/21] Create a book for Kernel development Mauro Carvalho Chehab
2016-09-14 11:06 ` [PATCH v3 01/21] doc: development-process: convert it to ReST markup Mauro Carvalho Chehab
2016-09-14 11:06 ` [PATCH v3 02/21] doc: development-process: rename files to rst Mauro Carvalho Chehab
2016-09-14 11:06 ` [PATCH v3 03/21] docs-rst: create a book for the development process Mauro Carvalho Chehab
2016-09-14 11:06 ` Mauro Carvalho Chehab [this message]
2016-09-14 11:06 ` [PATCH v3 05/21] Documentation/applying-patches.txt: convert it to ReST markup Mauro Carvalho Chehab
2016-09-16 17:10 ` Jonathan Corbet
2016-09-16 17:20 ` Joe Perches
2016-09-16 21:36 ` Mauro Carvalho Chehab
2016-09-16 20:25 ` Mauro Carvalho Chehab
2016-09-14 11:06 ` [PATCH v3 06/21] Documentation/Changes: " Mauro Carvalho Chehab
2016-09-14 11:06 ` [PATCH v3 07/21] Documentation/CodingStyle: Convert " Mauro Carvalho Chehab
2016-09-16 17:13 ` Jonathan Corbet
2016-09-16 20:34 ` Mauro Carvalho Chehab
2016-09-17 9:58 ` Mauro Carvalho Chehab
2016-09-14 11:06 ` [PATCH v3 08/21] Documentation/CodingStyle: use the proper tag for verbatim font Mauro Carvalho Chehab
2016-09-14 11:06 ` [PATCH v3 09/21] Documentation/CodingStyle: replace underline markups Mauro Carvalho Chehab
2016-09-14 11:06 ` [PATCH v3 10/21] Documentation/CodingStyle: use the .. note:: markup where needed Mauro Carvalho Chehab
2016-09-14 11:06 ` [PATCH v3 11/21] Documentation/kernel-docs.txt: convert it to ReST markup Mauro Carvalho Chehab
2016-09-16 17:15 ` Jonathan Corbet
2016-09-16 20:42 ` Mauro Carvalho Chehab
2016-09-16 21:00 ` Jonathan Corbet
2016-09-16 21:28 ` Mauro Carvalho Chehab
2016-09-14 11:06 ` [PATCH v3 12/21] Documentation/ManagementStyle: " Mauro Carvalho Chehab
2016-09-14 11:06 ` [PATCH v3 13/21] Documentation/SecurityBugs: " Mauro Carvalho Chehab
2016-09-16 17:17 ` Jonathan Corbet
2016-09-16 20:53 ` Mauro Carvalho Chehab
2016-09-14 11:06 ` [PATCH v3 14/21] Documentation/stable_api_nonsense.txt: " Mauro Carvalho Chehab
2016-09-14 11:06 ` [PATCH v3 15/21] Documentation/stable_kernel_rules.txt: " Mauro Carvalho Chehab
2016-09-14 11:06 ` [PATCH v3 16/21] Documentation/SubmittingDrivers: " Mauro Carvalho Chehab
2016-09-14 11:06 ` [PATCH v3 17/21] Documentation/SubmittingPatches: " Mauro Carvalho Chehab
2016-09-16 17:21 ` Jonathan Corbet
2016-09-16 22:14 ` Mauro Carvalho Chehab
2016-09-14 11:06 ` [PATCH v3 18/21] Documentation/HOWTO: add cross-references to other documents Mauro Carvalho Chehab
2016-09-14 11:06 ` [PATCH v3 19/21] docs-rst: move HOWTO and mentioned documents to development-process/ Mauro Carvalho Chehab
2016-09-16 17:23 ` Jonathan Corbet
2016-09-14 11:06 ` [PATCH v3 20/21] doc: adjust references to development-process Mauro Carvalho Chehab
2016-09-16 17:25 ` Jonathan Corbet
2016-09-16 22:21 ` Mauro Carvalho Chehab
2016-09-14 11:06 ` [PATCH v3 21/21] doc-rst: Add the new development-process/ files to Sphinx build Mauro Carvalho Chehab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=db76cc67bf1aa61345f226762b67532deb939ed1.1473849886.git.mchehab@s-opensource.com \
--to=mchehab@s-opensource.com \
--cc=corbet@lwn.net \
--cc=jani.nikula@linux.intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=markus.heiser@darmarit.de \
--cc=mchehab@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.