Documentation/process/5.Posting.rst

Source file repositories/reference/linux-study-clean/Documentation/process/5.Posting.rst

File Facts

System
Linux kernel
Corpus path
Documentation/process/5.Posting.rst
Extension
.rst
Size
18396 bytes
Lines
369
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_posting:

Posting patches
===============

Sooner or later, the time comes when your work is ready to be presented to
the community for review and, eventually, inclusion into the mainline
kernel.  Unsurprisingly, the kernel development community has evolved a set
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>`
and :ref:`Documentation/process/submit-checklist.rst <submitchecklist>`.


When to post
------------

There is a constant temptation to avoid posting patches before they are
completely "ready."  For simple patches, that is not a problem.  If the
work being done is complex, though, there is a lot to be gained by getting
feedback from the community before the work is complete.  So you should
consider posting in-progress work, or even making a git tree available so
that interested developers can catch up with your work at any time.

When posting code which is not yet considered ready for inclusion, it is a
good idea to say so in the posting itself.  Also mention any major work
which remains to be done and any known problems.  Fewer people will look at
patches which are known to be half-baked, but those who do will come in
with the idea that they can help you drive the work in the right direction.


Before creating patches
-----------------------

There are a number of things which should be done before you consider
sending patches to the development community.  These include:

 - Test the code to the extent that you can.  Make use of the kernel's
   debugging tools, ensure that the kernel will build with all reasonable
   combinations of configuration options, use cross-compilers to build for
   different architectures, etc. Add tests, likely using an existing
   testing framework like KUnit, and include them as a separate member
   of your series (see the next section for more about patch series).
   Note that this may be mandatory when affecting some subsystems. For
   example, library functions (resides under lib/) are extensively used
   almost everywhere and expected to be tested appropriately.

 - Make sure your code is compliant with the kernel coding style
   guidelines.

 - Does your change have performance implications?  If so, you should run
   benchmarks showing what the impact (or benefit) of your change is; a
   summary of the results should be included with the patch.

 - Be sure that you have the right to post the code.  If this work was done
   for an employer, the employer likely has a right to the work and must be
   agreeable with its release under the GPL.

As a general rule, putting in some extra thought before posting code almost
always pays back the effort in short order.


Patch preparation
-----------------

The preparation of patches for posting can be a surprising amount of work,
but, once again, attempting to save time here is not generally advisable
even in the short term.

Annotation

Implementation Notes