Documentation/process/1.Intro.rst

Source file repositories/reference/linux-study-clean/Documentation/process/1.Intro.rst

File Facts

System
Linux kernel
Corpus path
Documentation/process/1.Intro.rst
Extension
.rst
Size
14712 bytes
Lines
269
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. _development_process_intro:

Introduction
============

Executive summary
-----------------

The rest of this section covers the scope of the kernel development process
and the kinds of frustrations that developers and their employers can
encounter there.  There are a great many reasons why kernel code should be
merged into the official ("mainline") kernel, including automatic
availability to users, community support in many forms, and the ability to
influence the direction of kernel development.  Code contributed to the
Linux kernel must be made available under a GPL-compatible license.

:ref:`development_process` introduces the development process, the kernel
release cycle, and the mechanics of the merge window.  The various phases in
the patch development, review, and merging cycle are covered.  There is some
discussion of tools and mailing lists.  Developers wanting to get started
with kernel development are encouraged to track down and fix bugs as an
initial exercise.

:ref:`development_early_stage` covers early-stage project planning, with an
emphasis on involving the development community as soon as possible.

:ref:`development_coding` is about the coding process; several pitfalls which
have been encountered by other developers are discussed.  Some requirements for
patches are covered, and there is an introduction to some of the tools
which can help to ensure that kernel patches are correct.

:ref:`development_posting` talks about the process of posting patches for
review. To be taken seriously by the development community, patches must be
properly formatted and described, and they must be sent to the right place.
Following the advice in this section should help to ensure the best
possible reception for your work.

:ref:`development_followthrough` covers what happens after posting patches; the
job is far from done at that point.  Working with reviewers is a crucial part
of the development process; this section offers a number of tips on how to
avoid problems at this important stage.  Developers are cautioned against
assuming that the job is done when a patch is merged into the mainline.

:ref:`development_advancedtopics` introduces a couple of "advanced" topics:
managing patches with git and reviewing patches posted by others.

:ref:`development_conclusion` concludes the document with pointers to sources
for more information on kernel development.

What this document is about
---------------------------

The Linux kernel, at over 8 million lines of code and well over 1000
contributors to each release, is one of the largest and most active free
software projects in existence.  Since its humble beginning in 1991, this
kernel has evolved into a best-of-breed operating system component which
runs on pocket-sized digital music players, desktop PCs, the largest
supercomputers in existence, and all types of systems in between.  It is a
robust, efficient, and scalable solution for almost any situation.

With the growth of Linux has come an increase in the number of developers
(and companies) wishing to participate in its development.  Hardware
vendors want to ensure that Linux supports their products well, making
those products attractive to Linux users.  Embedded systems vendors, who
use Linux as a component in an integrated product, want Linux to be as
capable and well-suited to the task at hand as possible.  Distributors and
other software vendors who base their products on Linux have a clear
interest in the capabilities, performance, and reliability of the Linux
kernel.  And end users, too, will often wish to change Linux to make it
better suit their needs.

Annotation

Implementation Notes