Lines Matching full:patch
53 generated by :manpage:`diff(1)`. When creating your patch, make sure to
61 To create a patch for a single file, it is often sufficient to do::
70 diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patch
72 To create a patch for multiple files, you should unpack a "vanilla",
81 linux-3.19-vanilla $MYSRC > /tmp/patch
85 patch.
87 Make sure your patch does not include any extra files which do not
88 belong in a patch submission. Make sure to review your patch -after-
94 very important if you want your patch accepted.
105 Describe your problem. Whether your patch is a one-line bug fix or
134 The maintainer will thank you if you write your patch description in a
138 Solve only one problem per patch. If your description starts to get
139 long, that's a sign that you probably need to split up your patch.
142 When you submit or resubmit a patch or patch series, include the
143 complete patch description and justification for it. Don't just
144 say that this is version N of the patch (series). Don't expect the
145 subsystem maintainer to refer back to earlier patch versions or referenced
146 URLs to find the patch description and put that into the patch.
147 I.e., the patch (series) and its description should be self-contained.
149 probably didn't even receive earlier versions of the patch.
152 instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
156 If the patch fixes a logged bug entry, refer to that bug entry by
157 number and URL. If the patch follows from a mailing list discussion,
165 patch as submitted.
183 If your patch fixes a bug in a specific commit, e.g. you found an issue using
202 Separate each **logical change** into a separate patch.
210 group those changes into a single patch. Thus a single logical change
211 is contained within a single patch.
213 The point to remember is that each patch should make an easily understood
214 change that can be verified by reviewers. Each patch should be justifiable
217 If one patch depends on another patch in order for a change to be
218 complete, that is OK. Simply note **"this patch depends on patch X"**
219 in your patch description.
222 ensure that the kernel builds and runs properly after each patch in the
224 splitting your patch series at any point; they will not thank you if you
227 If you cannot condense your patch set into a smaller set of patches,
235 Check your patch for basic style violations, details of which can be
239 the reviewers time and will get your patch rejected, probably
244 the same patch which moves it. This clearly delineates the act of
249 Check your patches with the patch style checker prior to submission
260 patch.
263 5) Select the recipients for your patch
266 You should always copy the appropriate subsystem maintainer(s) on any patch
274 of your patch set. linux-kernel@vger.kernel.org functions as a list of
277 list; your patch will probably get more attention there. Please do not
292 If you have a patch that fixes an exploitable security bug, send that patch
294 to allow distributors to get the patch out to users; in such cases,
295 obviously, the patch should not be sent to any public lists.
302 into the sign-off area of your patch (note, NOT an email recipient). You
313 maintainer (as listed in the MAINTAINERS file) a man-pages patch, or at
318 For small patches you may want to CC the Trivial Patch Monkey
333 - Any fix by the author/maintainer of the file (ie. patch monkey
350 Be wary of your editor's word-wrap corrupting your patch,
351 if you choose to cut-n-paste your patch.
353 Do not attach the patch as a MIME attachment, compressed or not.
370 maintainers. If your patch, uncompressed, exceeds 300 kB in size,
371 it is preferred that you store your patch on an Internet-accessible
372 server, and provide instead a URL (link) pointing to your patch. But note
373 that if your patch exceeds 300 kB, it almost certainly needs to be broken up
379 Your patch will almost certainly get comments from reviewers on ways in
380 which the patch can be improved. You must respond to those comments;
396 busy people and may not get to your patch right away.
406 10) Include PATCH in the subject
410 convention to prefix your subject line with [PATCH]. This lets Linus
425 patch, which certifies that you wrote it or otherwise have the right to
426 pass it on as an open-source patch. The rules are pretty simple: if you
490 to insert an indication of the origin of a patch at the top of the commit
500 And here's what might appear in an older kernel once a patch is backported::
517 development of the patch, or that he/she was in the patch's delivery path.
520 patch but wishes to signify and record their approval of it then they can
521 ask to have an Acked-by: line added to the patch's changelog.
524 maintainer neither contributed to nor forwarded the patch.
527 has at least reviewed the patch and has indicated acceptance. Hence patch
532 Acked-by: does not necessarily indicate acknowledgement of the entire patch.
533 For example, if a patch affects multiple subsystems and has an Acked-by: from
539 If a person has had the opportunity to comment on a patch, but has not
540 provided such comments, you may optionally add a ``Cc:`` tag to the patch.
543 patch. This tag documents that potentially interested parties
546 A Co-Developed-by: states that the patch was also created by another developer
548 work on a single patch. Note, this person also needs to have a Signed-off-by:
549 line in the patch as well.
560 A Tested-by: tag indicates that the patch has been successfully tested (in
565 Reviewed-by:, instead, indicates that the patch has been reviewed and found
573 (a) I have carried out a technical review of this patch to
577 (b) Any problems, concerns, or questions relating to the patch
586 (d) While I have reviewed the patch and believe it to be sound, I
591 A Reviewed-by tag is a statement of opinion that the patch is an
594 offer a Reviewed-by tag for a patch. This tag serves to give credit to
596 done on the patch. Reviewed-by: tags, when supplied by reviewers known to
598 increase the likelihood of your patch getting into the kernel.
600 A Suggested-by: tag indicates that the patch idea is suggested by the person
607 A Fixes: tag indicates that the patch fixes an issue in a previous commit. It
611 method for indicating a bug fixed by the patch. See :ref:`describe_changes`
616 14) The canonical patch format
619 This section describes how the patch itself should be formatted. Note
620 that, if you have your patches stored in a ``git`` repository, proper patch
621 formatting can be had with ``git format-patch``. The tools cannot create
624 The canonical patch subject line is::
626 Subject: [PATCH 001/123] subsystem: summary phrase
628 The canonical patch message body contains the following:
630 - A ``from`` line specifying the patch author, followed by an empty
631 line (only needed if the person sending the patch is not the author).
634 be copied to the permanent changelog to describe this patch.
645 - The actual patch (``diff`` output).
656 describe the patch which that email contains. The ``summary
658 phrase`` for every patch in a whole patch series (where a ``patch
662 globally-unique identifier for that patch. It propagates all the way
664 developer discussions which refer to the patch. People will want to
666 patch. It will also be the only thing that people may quickly see
672 characters, and it must describe both what the patch changes, as well
673 as why the patch might be necessary. It is challenging to be both
678 brackets: "Subject: [PATCH <tag>...] <summary phrase>". The tags are
679 not considered part of the summary phrase, but describe how the patch
681 the multiple versions of the patch have been sent out in response to
683 comments. If there are four patches in a patch series the individual
687 the patch series.
691 Subject: [PATCH 2/5] ext2: improve scalability of bitmap searching
692 Subject: [PATCH v2 01/27] x86: fix eflags tracking
700 patch in the permanent changelog. If the ``from`` line is missing,
702 the patch author in the changelog.
707 have led to this patch. Including symptoms of the failure which the
708 patch addresses (kernel log messages, oops messages, etc.) is
710 looking for the applicable patch. If a patch fixes a compile failure,
712 enough that it is likely that someone searching for the patch can find
716 The ``---`` marker line serves the essential purpose of marking for patch
724 here. A good example of such comments might be ``patch changelogs``
726 patch.
734 See more details on the proper patch format in the following
742 It can be helpful to manually add In-Reply-To: headers to a patch
743 (e.g., when using ``git send-email``) to associate the patch with
745 the bug report. However, for a multi-patch series, it is generally
747 series. This way multiple versions of the patch don't become an
750 the cover email text) to link to an earlier version of the patch series.
762 the pull request as the cover letter for a normal posting of the patch
777 themselves, and a ``diffstat`` showing the overall effect of the patch series.
791 Once you have prepared a patch series in ``git`` that you wish to have somebody
811 Andrew Morton, "The perfect patch" (tpp).
814 Jeff Garzik, "Linux kernel patch submission format".
815 <http://linux.yyz.us/patch-format.html>
830 NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
836 Linus Torvalds's mail on the canonical patch format: