<!DOCTYPE html>
<html lang="en" data-content_root="../">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>1. Introduction — The Linux Kernel documentation</title>
<link rel="stylesheet" type="text/css" href="../_static/pygments.css?v=fa44fd50" />
<link rel="stylesheet" type="text/css" href="../_static/alabaster.css?v=3918102e" />
<script src="../_static/documentation_options.js?v=5929fcd5"></script>
<script src="../_static/doctools.js?v=9bcbadda"></script>
<script src="../_static/sphinx_highlight.js?v=dc90522c"></script>
<link rel="index" title="Index" href="../genindex.html" />
<link rel="search" title="Search" href="../search.html" />
<link rel="next" title="2. How the development process works" href="2.Process.html" />
<link rel="prev" title="A guide to the Kernel Development Process" href="development-process.html" />
<link rel="stylesheet" href="../_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="../index.html">
<img class="logo" src="../_static/logo.svg" alt="Logo of The Linux Kernel"/>
</a></p>
<h1 class="logo"><a href="../index.html">The Linux Kernel</a></h1>
<p class="blurb">6.18.50</p>
<search id="searchbox" style="display: none" role="search">
<h3 id="searchlabel">Quick search</h3>
<div class="searchformwrapper">
<form class="search" action="../search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script>
<p>
<h3 class="kernel-toc-contents">Contents</h3>
<input type="checkbox" class="kernel-toc-toggle" id = "kernel-toc-toggle" checked>
<label class="kernel-toc-title" for="kernel-toc-toggle"></label>
<div class="kerneltoc" id="kerneltoc">
<ul class="current">
<li class="toctree-l1 current"><a class="reference internal" href="development-process.html">Development process</a><ul class="current">
<li class="toctree-l2 current"><a class="current reference internal" href="#">1. Introduction</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#executive-summary">1.1. Executive summary</a></li>
<li class="toctree-l3"><a class="reference internal" href="#what-this-document-is-about">1.2. What this document is about</a></li>
<li class="toctree-l3"><a class="reference internal" href="#credits">1.3. Credits</a></li>
<li class="toctree-l3"><a class="reference internal" href="#the-importance-of-getting-code-into-the-mainline">1.4. The importance of getting code into the mainline</a></li>
<li class="toctree-l3"><a class="reference internal" href="#licensing">1.5. Licensing</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="2.Process.html">2. How the development process works</a></li>
<li class="toctree-l2"><a class="reference internal" href="3.Early-stage.html">3. Early-stage planning</a></li>
<li class="toctree-l2"><a class="reference internal" href="4.Coding.html">4. Getting the code right</a></li>
<li class="toctree-l2"><a class="reference internal" href="5.Posting.html">5. Posting patches</a></li>
<li class="toctree-l2"><a class="reference internal" href="6.Followthrough.html">6. Followthrough</a></li>
<li class="toctree-l2"><a class="reference internal" href="7.AdvancedTopics.html">7. Advanced topics</a></li>
<li class="toctree-l2"><a class="reference internal" href="8.Conclusion.html">8. For more information</a></li>
<li class="toctree-l2"><a class="reference internal" href="8.Conclusion.html#conclusion">9. Conclusion</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="submitting-patches.html">Submitting patches</a></li>
<li class="toctree-l1"><a class="reference internal" href="code-of-conduct.html">Code of conduct</a></li>
<li class="toctree-l1"><a class="reference internal" href="../maintainer/index.html">Maintainer handbook</a></li>
<li class="toctree-l1 current"><a class="reference internal" href="index.html">All development-process docs</a><ul class="current">
<li class="toctree-l2 current"><a class="reference internal" href="index.html#an-introduction-to-how-kernel-development-works">An introduction to how kernel development works</a><ul class="current">
<li class="toctree-l3"><a class="reference internal" href="howto.html">HOWTO do Linux kernel development</a></li>
<li class="toctree-l3 current"><a class="reference internal" href="development-process.html">A guide to the Kernel Development Process</a></li>
<li class="toctree-l3"><a class="reference internal" href="submitting-patches.html">Submitting patches: the essential guide to getting your code into the kernel</a></li>
<li class="toctree-l3"><a class="reference internal" href="submit-checklist.html">Linux Kernel patch submission checklist</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="index.html#tools-and-technical-guides-for-kernel-developers">Tools and technical guides for kernel developers</a></li>
<li class="toctree-l2"><a class="reference internal" href="index.html#policy-guides-and-developer-statements">Policy guides and developer statements</a></li>
<li class="toctree-l2"><a class="reference internal" href="index.html#dealing-with-bugs">Dealing with bugs</a></li>
<li class="toctree-l2"><a class="reference internal" href="index.html#maintainer-information">Maintainer information</a></li>
<li class="toctree-l2"><a class="reference internal" href="index.html#other-material">Other material</a></li>
</ul>
</li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../core-api/index.html">Core API</a></li>
<li class="toctree-l1"><a class="reference internal" href="../driver-api/index.html">Driver APIs</a></li>
<li class="toctree-l1"><a class="reference internal" href="../subsystem-apis.html">Subsystems</a></li>
<li class="toctree-l1"><a class="reference internal" href="../locking/index.html">Locking</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="license-rules.html">Licensing rules</a></li>
<li class="toctree-l1"><a class="reference internal" href="../doc-guide/index.html">Writing documentation</a></li>
<li class="toctree-l1"><a class="reference internal" href="../dev-tools/index.html">Development tools</a></li>
<li class="toctree-l1"><a class="reference internal" href="../dev-tools/testing-overview.html">Testing guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="../kernel-hacking/index.html">Hacking guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="../trace/index.html">Tracing</a></li>
<li class="toctree-l1"><a class="reference internal" href="../fault-injection/index.html">Fault injection</a></li>
<li class="toctree-l1"><a class="reference internal" href="../livepatch/index.html">Livepatching</a></li>
<li class="toctree-l1"><a class="reference internal" href="../rust/index.html">Rust</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../admin-guide/index.html">Administration</a></li>
<li class="toctree-l1"><a class="reference internal" href="../kbuild/index.html">Build system</a></li>
<li class="toctree-l1"><a class="reference internal" href="../admin-guide/reporting-issues.html">Reporting issues</a></li>
<li class="toctree-l1"><a class="reference internal" href="../tools/index.html">Userspace tools</a></li>
<li class="toctree-l1"><a class="reference internal" href="../userspace-api/index.html">Userspace API</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../firmware-guide/index.html">Firmware</a></li>
<li class="toctree-l1"><a class="reference internal" href="../devicetree/index.html">Firmware and Devicetree</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../arch/index.html">CPU architectures</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../staging/index.html">Unsorted documentation</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../translations/index.html">Translations</a></li>
</ul>
</div>
<script type="text/javascript"> <!--
var sbar = document.getElementsByClassName("sphinxsidebar")[0];
let currents = document.getElementsByClassName("current")
if (currents.length) {
sbar.scrollTop = currents[currents.length - 1].offsetTop;
}
--> </script>
<div role="note" aria-label="source link">
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../_sources/process/1.Intro.rst.txt"
rel="nofollow">Show Source</a></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<div class="language-selection">
English
<ul>
<li><a href="../translations/zh_CN/process/1.Intro.html">Chinese (Simplified)</a></li>
<li><a href="../translations/zh_TW/process/1.Intro.html">Chinese (Traditional)</a></li>
<li><a href="../translations/it_IT/process/1.Intro.html">Italian</a></li>
<li><a href="../translations/sp_SP/process/1.Intro.html">Spanish</a></li>
</ul>
</div>
<section id="introduction">
<span id="development-process-intro"></span><h1><span class="section-number">1. </span>Introduction<a class="headerlink" href="#introduction" title="Link to this heading">¶</a></h1>
<section id="executive-summary">
<h2><span class="section-number">1.1. </span>Executive summary<a class="headerlink" href="#executive-summary" title="Link to this heading">¶</a></h2>
<p>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.</p>
<p><a class="reference internal" href="2.Process.html#development-process"><span class="std std-ref">How the development process works</span></a> 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.</p>
<p><a class="reference internal" href="3.Early-stage.html#development-early-stage"><span class="std std-ref">Early-stage planning</span></a> covers early-stage project planning, with an
emphasis on involving the development community as soon as possible.</p>
<p><a class="reference internal" href="4.Coding.html#development-coding"><span class="std std-ref">Getting the code right</span></a> 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.</p>
<p><a class="reference internal" href="5.Posting.html#development-posting"><span class="std std-ref">Posting patches</span></a> 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.</p>
<p><a class="reference internal" href="6.Followthrough.html#development-followthrough"><span class="std std-ref">Followthrough</span></a> 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.</p>
<p><a class="reference internal" href="7.AdvancedTopics.html#development-advancedtopics"><span class="std std-ref">Advanced topics</span></a> introduces a couple of “advanced” topics:
managing patches with git and reviewing patches posted by others.</p>
<p><a class="reference internal" href="8.Conclusion.html#development-conclusion"><span class="std std-ref">For more information</span></a> concludes the document with pointers to sources
for more information on kernel development.</p>
</section>
<section id="what-this-document-is-about">
<h2><span class="section-number">1.2. </span>What this document is about<a class="headerlink" href="#what-this-document-is-about" title="Link to this heading">¶</a></h2>
<p>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.</p>
<p>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.</p>
<p>One of the most compelling features of Linux is that it is accessible to
these developers; anybody with the requisite skills can improve Linux and
influence the direction of its development. Proprietary products cannot
offer this kind of openness, which is a characteristic of the free software
process. But, if anything, the kernel is even more open than most other
free software projects. A typical three-month kernel development cycle can
involve over 1000 developers working for more than 100 different companies
(or for no company at all).</p>
<p>Working with the kernel development community is not especially hard. But,
that notwithstanding, many potential contributors have experienced
difficulties when trying to do kernel work. The kernel community has
evolved its own distinct ways of operating which allow it to function
smoothly (and produce a high-quality product) in an environment where
thousands of lines of code are being changed every day. So it is not
surprising that Linux kernel development process differs greatly from
proprietary development methods.</p>
<p>The kernel’s development process may come across as strange and
intimidating to new developers, but there are good reasons and solid
experience behind it. A developer who does not understand the kernel
community’s ways (or, worse, who tries to flout or circumvent them) will
have a frustrating experience in store. The development community, while
being helpful to those who are trying to learn, has little time for those
who will not listen or who do not care about the development process.</p>
<p>It is hoped that those who read this document will be able to avoid that
frustrating experience. There is a lot of material here, but the effort
involved in reading it will be repaid in short order. The development
community is always in need of developers who will help to make the kernel
better; the following text should help you - or those who work for you -
join our community.</p>
</section>
<section id="credits">
<h2><span class="section-number">1.3. </span>Credits<a class="headerlink" href="#credits" title="Link to this heading">¶</a></h2>
<p>This document was written by Jonathan Corbet, <a class="reference external" href="mailto:corbet%40lwn.net">corbet<span>@</span>lwn<span>.</span>net</a>. It has been
improved by comments from Johannes Berg, James Berry, Alex Chiang, Roland
Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh,
Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata, and
Jochen Voß.</p>
<p>This work was supported by the Linux Foundation; thanks especially to
Amanda McPherson, who saw the value of this effort and made it all happen.</p>
</section>
<section id="the-importance-of-getting-code-into-the-mainline">
<h2><span class="section-number">1.4. </span>The importance of getting code into the mainline<a class="headerlink" href="#the-importance-of-getting-code-into-the-mainline" title="Link to this heading">¶</a></h2>
<p>Some companies and developers occasionally wonder why they should bother
learning how to work with the kernel community and get their code into the
mainline kernel (the “mainline” being the kernel maintained by Linus
Torvalds and used as a base by Linux distributors). In the short term,
contributing code can look like an avoidable expense; it seems easier to
just keep the code separate and support users directly. The truth of the
matter is that keeping code separate (“out of tree”) is a false economy.</p>
<p>As a way of illustrating the costs of out-of-tree code, here are a few
relevant aspects of the kernel development process; most of these will be
discussed in greater detail later in this document. Consider:</p>
<ul>
<li><p>Code which has been merged into the mainline kernel is available to all
Linux users. It will automatically be present on all distributions which
enable it. There is no need for driver disks, downloads, or the hassles
of supporting multiple versions of multiple distributions; it all just
works, for the developer and for the user. Incorporation into the
mainline solves a large number of distribution and support problems.</p></li>
<li><p>While kernel developers strive to maintain a stable interface to user
space, the internal kernel API is in constant flux. The lack of a stable
internal interface is a deliberate design decision; it allows fundamental
improvements to be made at any time and results in higher-quality code.
But one result of that policy is that any out-of-tree code requires
constant upkeep if it is to work with new kernels. Maintaining
out-of-tree code requires significant amounts of work just to keep that
code working.</p>
<p>Code which is in the mainline, instead, does not require this work as the
result of a simple rule requiring any developer who makes an API change
to also fix any code that breaks as the result of that change. So code
which has been merged into the mainline has significantly lower
maintenance costs.</p>
</li>
<li><p>Beyond that, code which is in the kernel will often be improved by other
developers. Surprising results can come from empowering your user
community and customers to improve your product.</p></li>
<li><p>Kernel code is subjected to review, both before and after merging into
the mainline. No matter how strong the original developer’s skills are,
this review process invariably finds ways in which the code can be
improved. Often review finds severe bugs and security problems. This is
especially true for code which has been developed in a closed
environment; such code benefits strongly from review by outside
developers. Out-of-tree code is lower-quality code.</p></li>
<li><p>Participation in the development process is your way to influence the
direction of kernel development. Users who complain from the sidelines
are heard, but active developers have a stronger voice - and the ability
to implement changes which make the kernel work better for their needs.</p></li>
<li><p>When code is maintained separately, the possibility that a third party
will contribute a different implementation of a similar feature always
exists. Should that happen, getting your code merged will become much
harder - to the point of impossibility. Then you will be faced with the
unpleasant alternatives of either (1) maintaining a nonstandard feature
out of tree indefinitely, or (2) abandoning your code and migrating your
users over to the in-tree version.</p></li>
<li><p>Contribution of code is the fundamental action which makes the whole
process work. By contributing your code you can add new functionality to
the kernel and provide capabilities and examples which are of use to
other kernel developers. If you have developed code for Linux (or are
thinking about doing so), you clearly have an interest in the continued
success of this platform; contributing code is one of the best ways to
help ensure that success.</p></li>
</ul>
<p>All of the reasoning above applies to any out-of-tree kernel code,
including code which is distributed in proprietary, binary-only form.
There are, however, additional factors which should be taken into account
before considering any sort of binary-only kernel code distribution. These
include:</p>
<ul class="simple">
<li><p>The legal issues around the distribution of proprietary kernel modules
are cloudy at best; quite a few kernel copyright holders believe that
most binary-only modules are derived products of the kernel and that, as
a result, their distribution is a violation of the GNU General Public
license (about which more will be said below). Your author is not a
lawyer, and nothing in this document can possibly be considered to be
legal advice. The true legal status of closed-source modules can only be
determined by the courts. But the uncertainty which haunts those modules
is there regardless.</p></li>
<li><p>Binary modules greatly increase the difficulty of debugging kernel
problems, to the point that most kernel developers will not even try. So
the distribution of binary-only modules will make it harder for your
users to get support from the community.</p></li>
<li><p>Support is also harder for distributors of binary-only modules, who must
provide a version of the module for every distribution and every kernel
version they wish to support. Dozens of builds of a single module can
be required to provide reasonably comprehensive coverage, and your users
will have to upgrade your module separately every time they upgrade their
kernel.</p></li>
<li><p>Everything that was said above about code review applies doubly to
closed-source code. Since this code is not available at all, it cannot
have been reviewed by the community and will, beyond doubt, have serious
problems.</p></li>
</ul>
<p>Makers of embedded systems, in particular, may be tempted to disregard much
of what has been said in this section in the belief that they are shipping
a self-contained product which uses a frozen kernel version and requires no
more development after its release. This argument misses the value of
widespread code review and the value of allowing your users to add
capabilities to your product. But these products, too, have a limited
commercial life, after which a new version must be released. At that
point, vendors whose code is in the mainline and well maintained will be
much better positioned to get the new product ready for market quickly.</p>
</section>
<section id="licensing">
<h2><span class="section-number">1.5. </span>Licensing<a class="headerlink" href="#licensing" title="Link to this heading">¶</a></h2>
<p>Code is contributed to the Linux kernel under a number of licenses, but all
code must be compatible with version 2 of the GNU General Public License
(GPLv2), which is the license covering the kernel distribution as a whole.
In practice, that means that all code contributions are covered either by
GPLv2 (with, optionally, language allowing distribution under later
versions of the GPL) or the three-clause BSD license. Any contributions
which are not covered by a compatible license will not be accepted into the
kernel.</p>
<p>Copyright assignments are not required (or requested) for code contributed
to the kernel. All code merged into the mainline kernel retains its
original ownership; as a result, the kernel now has thousands of owners.</p>
<p>One implication of this ownership structure is that any attempt to change
the licensing of the kernel is doomed to almost certain failure. There are
few practical scenarios where the agreement of all copyright holders could
be obtained (or their code removed from the kernel). So, in particular,
there is no prospect of a migration to version 3 of the GPL in the
foreseeable future.</p>
<p>It is imperative that all code contributed to the kernel be legitimately
free software. For that reason, code from contributors without a known
identity or anonymous contributors will not be accepted. All contributors are
required to “sign off” on their code, stating that the code can be distributed
with the kernel under the GPL. Code which has not been licensed as free
software by its owner, or which risks creating copyright-related problems for
the kernel (such as code which derives from reverse-engineering efforts lacking
proper safeguards) cannot be contributed.</p>
<p>Questions about copyright-related issues are common on Linux development
mailing lists. Such questions will normally receive no shortage of
answers, but one should bear in mind that the people answering those
questions are not lawyers and cannot provide legal advice. If you have
legal questions relating to Linux source code, there is no substitute for
talking with a lawyer who understands this field. Relying on answers
obtained on technical mailing lists is a risky affair.</p>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="footer">
©The kernel development community.
|
Powered by <a href="https://www.sphinx-doc.org/">Sphinx 8.1.3</a>
& <a href="https://alabaster.readthedocs.io">Alabaster 0.7.16</a>
|
<a href="../_sources/process/1.Intro.rst.txt"
rel="nofollow">Page source</a>
</div>
</body>
</html>