Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 022e04d6 authored by Mauro Carvalho Chehab's avatar Mauro Carvalho Chehab Committed by Jonathan Corbet
Browse files

Documentation/HOWTO: convert to ReST notation 



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: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
parent f0ddda3e

Documentation/HOWTO

+49 −4
Original line number Original line Diff line number Diff line 
HOWTO do Linux kernel development

HOWTO do Linux kernel development

---------------------------------

=================================





This is the be-all, end-all document on this topic.  It contains

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

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

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

are not a good substitute for a solid C education and/or years of

experience, the following books are good for, if anything, reference:

experience, the following books are good for, if anything, reference:



 - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]

 - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]

 - "Practical C Programming" by Steve Oualline [O'Reilly]

 - "Practical C Programming" by Steve Oualline [O'Reilly]

 - "C:  A Reference Manual" by Harbison and Steele [Prentice Hall]

 - "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.

their statements on legal matters.





For common questions and answers about the GPL, please see:

For common questions and answers about the GPL, please see:



	http://www.gnu.org/licenses/gpl-faq.html

	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

Here is a list of files that are in the kernel source tree that are

required reading:

required reading:



  README

  README

    This file gives a short background on the Linux kernel and describes

    This file gives a short background on the Linux kernel and describes

    what is necessary to do to configure and build the kernel.  People

    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

    patches if these rules are followed, and many people will only

    review code if it is in the proper style.

    review code if it is in the proper style.





  Documentation/SubmittingPatches

  Documentation/SubmittingPatches and Documentation/SubmittingDrivers

  Documentation/SubmittingDrivers

    These files describe in explicit detail how to successfully create

    These files describe in explicit detail how to successfully create

    and send a patch, including (but not limited to):

    and send a patch, including (but not limited to):



       - Email contents

       - Email contents

       - Email format

       - Email format

       - Who to send it to

       - Who to send it to



    Following these rules will not guarantee success (as all patches are

    Following these rules will not guarantee success (as all patches are

    subject to scrutiny for content and style), but not following them

    subject to scrutiny for content and style), but not following them

    will almost always prevent it.

    will almost always prevent it.





    Other excellent descriptions of how to create patches properly are:

    Other excellent descriptions of how to create patches properly are:



	"The Perfect Patch"

	"The Perfect Patch"



		http://www.ozlabs.org/~akpm/stuff/tpp.txt

		http://www.ozlabs.org/~akpm/stuff/tpp.txt



	"Linux kernel patch submission format"

	"Linux kernel patch submission format"



		http://linux.yyz.us/patch-format.html

		http://linux.yyz.us/patch-format.html





  Documentation/stable_api_nonsense.txt

  Documentation/stable_api_nonsense.txt

    This file describes the rationale behind the conscious decision to

    This file describes the rationale behind the conscious decision to

    not have a stable API within the kernel, including things like:

    not have a stable API within the kernel, including things like:



      - Subsystem shim-layers (for compatibility?)

      - Subsystem shim-layers (for compatibility?)

      - Driver portability between Operating Systems.

      - Driver portability between Operating Systems.

      - Mitigating rapid change within the kernel source tree (or

      - Mitigating rapid change within the kernel source tree (or

	preventing rapid change)

	preventing rapid change)



    This document is crucial for understanding the Linux development

    This document is crucial for understanding the Linux development

    philosophy and is very important for people moving to Linux from

    philosophy and is very important for people moving to Linux from

    development on other Operating Systems.

    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

locking properly.  The documents will be created in the

Documentation/DocBook/ directory and can be generated as PDF,

Documentation/DocBook/ directory and can be generated as PDF,

Postscript, HTML, and man pages by running:

Postscript, HTML, and man pages by running:



::



	make pdfdocs

	make pdfdocs

	make psdocs

	make psdocs

	make htmldocs

	make htmldocs

	make mandocs

	make mandocs



respectively from the main kernel source directory.

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

If you do not know anything about Linux kernel development, you should

look at the Linux KernelNewbies project:

look at the Linux KernelNewbies project:



	http://kernelnewbies.org

	http://kernelnewbies.org



It consists of a helpful mailing list where you can ask almost any type

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

of basic kernel development question (make sure to search the archives

first, before asking something that has already been answered in the

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

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,

some task to start doing to join into the kernel development community,

go to the Linux Kernel Janitor's project:

go to the Linux Kernel Janitor's project:



	http://kernelnewbies.org/KernelJanitors

	http://kernelnewbies.org/KernelJanitors



It is a great place to start.  It describes a list of relatively simple

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

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

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

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

kernel-mentors project was created to help you out with this.  It is a

mailing list, and can be found at:

mailing list, and can be found at:



	http://selenic.com/mailman/listinfo/kernel-mentors

	http://selenic.com/mailman/listinfo/kernel-mentors





Before making any actual modifications to the Linux kernel code, it is

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

Cross-Reference project, which is able to present source code in a

self-referential, indexed webpage format. An excellent up-to-date

self-referential, indexed webpage format. An excellent up-to-date

repository of the kernel code may be found at:

repository of the kernel code may be found at:



	http://lxr.free-electrons.com/

	http://lxr.free-electrons.com/
@@ -218,6 +238,7 @@ The development process 
Linux kernel development process currently consists of a few different

Linux kernel development process currently consists of a few different

main kernel "branches" and lots of different subsystem-specific kernel

main kernel "branches" and lots of different subsystem-specific kernel

branches.  These different branches are:

branches.  These different branches are:



  - main 4.x kernel tree

  - main 4.x kernel tree

  - 4.x.y -stable kernel tree

  - 4.x.y -stable kernel tree

  - 4.x -git kernel patches

  - 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

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

kernel.org in the pub/linux/kernel/v4.x/ directory.  Its development

process is as follows:

process is as follows:



  - As soon as a new kernel is released a two weeks window is open,

  - 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

    during this period of time maintainers can submit big diffs to

    Linus, usually the patches that have already been included in the

    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

It is worth mentioning what Andrew Morton wrote on the linux-kernel

mailing list about kernel releases:

mailing list about kernel releases:



::



	"Nobody knows when a kernel will be released, because it's

	"Nobody knows when a kernel will be released, because it's

	released according to perceived bug status, not according to a

	released according to perceived bug status, not according to a

	preconceived timeline."

	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

tree, they need to be integration-tested.  For this purpose, a special

testing repository exists into which virtually all subsystem trees are

testing repository exists into which virtually all subsystem trees are

pulled on an almost daily basis:

pulled on an almost daily basis:



	http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git

	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

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

bugzilla.kernel.org is where the Linux kernel developers track kernel

bugs.  Users are encouraged to report all bugs that they find in this

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:

tool.  For details on how to use the kernel bugzilla, please see:



	http://bugzilla.kernel.org/page.cgi?id=faq.html

	http://bugzilla.kernel.org/page.cgi?id=faq.html





The file REPORTING-BUGS in the main kernel source directory has a good

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

As some of the above documents describe, the majority of the core kernel

developers participate on the Linux Kernel Mailing list.  Details on how

developers participate on the Linux Kernel Mailing list.  Details on how

to subscribe and unsubscribe from the list can be found at:

to subscribe and unsubscribe from the list can be found at:



	http://vger.kernel.org/vger-lists.html#linux-kernel

	http://vger.kernel.org/vger-lists.html#linux-kernel



There are archives of the mailing list on the web in many different

There are archives of the mailing list on the web in many different

places.  Use a search engine to find these archives.  For example:

places.  Use a search engine to find these archives.  For example:



	http://dir.gmane.org/gmane.linux.kernel

	http://dir.gmane.org/gmane.linux.kernel



It is highly recommended that you search the archives about the topic

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

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

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

Many of the lists are hosted on kernel.org. Information on them can be

found at:

found at:



	http://vger.kernel.org/vger-lists.html

	http://vger.kernel.org/vger-lists.html





Please remember to follow good behavioral habits when using the lists.

Please remember to follow good behavioral habits when using the lists.

Though a bit cheesy, the following URL has some simple guidelines for

Though a bit cheesy, the following URL has some simple guidelines for

interacting with the list (or any list):

interacting with the list (or any list):



	http://www.albion.com/netiquette/

	http://www.albion.com/netiquette/





If multiple people respond to your mail, the CC: list of recipients may

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

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

on its technical merits and those alone.  So, what should you be

expecting?

expecting?



  - criticism

  - criticism

  - comments

  - comments

  - requests for change

  - 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.

again, sometimes things get lost in the huge volume.





What should you not do?

What should you not do?



  - expect your patch to be accepted without question

  - expect your patch to be accepted without question

  - become defensive

  - become defensive

  - ignore comments

  - ignore comments
@@ -457,7 +492,9 @@ Differences between the kernel community and corporate structures 
The kernel community works differently than most traditional corporate

The kernel community works differently than most traditional corporate

development environments.  Here are a list of things that you can try to

development environments.  Here are a list of things that you can try to

do to avoid problems:

do to avoid problems:



  Good things to say regarding your proposed changes:

  Good things to say regarding your proposed changes:



    - "This solves multiple problems."

    - "This solves multiple problems."

    - "This deletes 2000 lines of code."

    - "This deletes 2000 lines of code."

    - "Here is a patch that explains what I am trying to describe."

    - "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..."

    - "This increases performance on typical machines..."





  Bad things you should avoid saying:

  Bad things you should avoid saying:



    - "We did it this way in AIX/ptx/Solaris, so therefore it must be

    - "We did it this way in AIX/ptx/Solaris, so therefore it must be

      good..."

      good..."

    - "I've being doing this for 20 years, so..."

    - "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.

   and simplify (or simply re-order) patches before submitting them.





Here is an analogy from kernel developer Al Viro:

Here is an analogy from kernel developer Al Viro:



::



	"Think of a teacher grading homework from a math student.  The

	"Think of a teacher grading homework from a math student.  The

	teacher does not want to see the student's trials and errors

	teacher does not want to see the student's trials and errors

	before they came up with the solution. They want to see the

	before they came up with the solution. They want to see the

	cleanest, most elegant answer.  A good student knows this, and

	cleanest, most elegant answer.  A good student knows this, and

	would never submit her intermediate work before the final

	would never submit her intermediate work before the final

	solution."

	solution.





	The same is true of kernel development. The maintainers and

	The same is true of kernel development. The maintainers and

	reviewers do not want to see the thought process behind the

	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

the text in your email.  This information will become the ChangeLog

information for the patch, and will be preserved for everyone to see for

information for the patch, and will be preserved for everyone to see for

all time.  It should describe the patch completely, containing:

all time.  It should describe the patch completely, containing:



  - why the change is necessary

  - why the change is necessary

  - the overall design approach in the patch

  - the overall design approach in the patch

  - implementation details

  - 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

For more details on what this should all look like, please see the

ChangeLog section of the document:

ChangeLog section of the document:



  "The Perfect Patch"

  "The Perfect Patch"



      http://www.ozlabs.org/~akpm/stuff/tpp.txt

      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"

Thanks to Paolo Ciarrocchi who allowed the "Development Process"

(http://lwn.net/Articles/94386/) section

(http://lwn.net/Articles/94386/) section

to be based on text he had written, and to Randy Dunlap and Gerrit

to be based on text he had written, and to Randy Dunlap and Gerrit