| /Linux-v4.19/Documentation/process/ |
| D | applying-patches.rst | 19 In addition to explaining how to apply and revert patches, a brief
21 their specific patches) is also provided.
144 If you don't have any third-party patches applied to your kernel source, but
145 only patches from kernel.org and you apply the patches in the correct order,
157 in the wrong directory. Less often, you'll find patches that need to be
203 So if you get these errors with kernel.org patches then you should probably
216 generate a patch representing the differences between two patches and then
220 step. The -z flag to interdiff will even let you feed it patches in gzip or
232 downloading and applying of patches (http://www.selenic.com/ketchup/).
241 Where can I download the patches?
[all …]
|
| D | email-clients.rst | 11 end, maintainers use ``git am`` to apply the patches.
28 Email clients that are used for Linux kernel patches should send the
32 Don't send patches with ``format=flowed``. This can cause unexpected
39 Emailed patches should be in ASCII or UTF-8 encoding only.
46 Copy-and-paste (or cut-and-paste) usually does not work for patches
51 Don't use PGP/GPG signatures in mail that contains patches.
52 This breaks many scripts that read and apply the patches.
56 and successfully apply it with 'patch' before sending patches to Linux
64 patches for the Linux kernel. These are not meant to be complete
90 Works. Some people use this successfully for patches.
[all …]
|
| D | 5.Posting.rst | 3 Posting patches
9 of conventions and procedures which are used in the posting of patches;
12 more information can also be found in the files process/submitting-patches.rst,
20 There is a constant temptation to avoid posting patches before they are
21 completely "ready." For simple patches, that is not a problem. If the
30 patches which are known to be half-baked, but those who do will come in
34 Before creating patches
38 sending patches to the development community. These include:
63 The preparation of patches for posting can be a surprising amount of work,
81 up patches is a bit of an art; some developers spend a long time figuring
[all …]
|
| D | stable-kernel-rules.rst | 6 Rules on what kind of patches are accepted, and which ones are not, into the
30 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
35 Procedure for submitting patches to the -stable tree
41 - Security patches should not be handled (solely) by the -stable review
101 Additionally, some patches submitted via Option 1 may have additional patch
122 Also, some patches may have kernel version prerequisites. This can be
149 - When the -stable maintainers decide for a review cycle, the patches will be
157 - At the end of the review cycle, the ACKed patches will be added to the
159 - Security patches will be accepted into the -stable tree directly from the
166 - The queues of patches, for both completed versions and in progress
|
| D | submitting-patches.rst | 3 Submitting patches: the essential guide to getting your code into the kernel
18 for device tree binding patches, read
19 Documentation/devicetree/bindings/submitting-patches.txt.
22 control system; if you use ``git`` to prepare your patches, you'll find much
24 and document a sensible set of patches. In general, use of ``git`` will make
38 patches prepared against those trees. See the **T:** entry for the subsystem
48 If you must generate your patches by hand, use ``diff -up`` or ``diff -uprN``
49 to create patches. Git generates patches in this form by default; if
52 All changes to the Linux kernel occur in the form of patches, as
92 individual patches which modify things in logical stages; see
[all …]
|
| D | 2.Process.rst | 36 merging of patches for each release. At the beginning of each development
41 this time, at a rate approaching 1,000 changes ("patches," or "changesets")
57 Over the next six to ten weeks, only patches which fix problems should be
92 serious. For this reason, patches which cause regressions are looked upon
214 How patches get into the Kernel
217 There is exactly one person who can merge patches into the mainline kernel
218 repository: Linus Torvalds. But, of the over 9,500 patches which went
236 maintainers to track a list of patches, including authorship information
238 patches in his or her repository are not found in the mainline.
241 the patches they have selected for merging from their repositories. If
[all …]
|
| D | howto.rst | 10 If anything in this document becomes out of date, please send in patches
102 patches if these rules are followed, and many people will only
105 …:ref:`Documentation/process/submitting-patches.rst <submittingpatches>` and :ref:`Documentation/pr…
113 Following these rules will not guarantee success (as all patches are
117 Other excellent descriptions of how to create patches properly are:
160 :ref:`Documentation/process/applying-patches.rst <applying_patches>`
237 - 4.x -git kernel patches
238 - subsystem specific kernel trees and patches
250 Linus, usually the patches that have already been included in the
253 can be found at https://git-scm.com/) but plain patches are also just
[all …]
|
| D | 7.AdvancedTopics.rst | 11 Managing patches with git
23 Managing patches with git can make life much easier for the developer,
24 especially as the volume of those patches grows. Git also has its rough
39 understanding of how git works before trying to use it to make patches
49 Using git to generate patches for submission by email can be a good
65 Publicly-available branches should be created with care; merge in patches
115 mass movement of patches from one repository to another makes it easy to
118 thing happening; putting up a git tree with unreviewed or off-topic patches
123 You can send me patches, but for me to pull a git patch from you, I
130 To avoid this kind of situation, ensure that all patches within a given
[all …]
|
| D | 6.Followthrough.rst | 8 patches. One of the biggest mistakes that even experienced kernel
10 posting patches indicates a transition into the next stage of the process,
19 prevent the inclusion of your patches into the mainline.
81 that your patches go nowhere.
112 dedicated to patches planned for the next merge window, and another for
115 For patches applying to areas for which there is no obvious subsystem tree
116 (memory management patches, for example), the default tree often ends up
130 burner so that the remaining patches can be worked into shape and merged.
132 developers and, possibly, moving some patches between trees to ensure that
171 for; you can start creating cool new patches once any problems with the old
[all …]
|
| D | index.rst | 26 submitting-patches
52 applying-patches
|
| /Linux-v4.19/Documentation/bpf/ |
| D | bpf_devel_QA.rst | 6 workflows related to reporting bugs, submitting patches, and queueing
7 patches for stable kernels.
9 For general information about submitting patches, please refer to
44 Submitting patches
47 Q: To which mailing list do I need to submit my BPF patches?
49 A: Please submit your BPF patches to the netdev kernel mailing list:
55 many other subsystems as well, the patches are still routed mainly
61 the changes and provide their Acked-by's to the patches.
63 Q: Where can I find patches currently under discussion for BPF subsystem?
65 A: All patches that are Cc'ed to netdev are queued for review under netdev
[all …]
|
| /Linux-v4.19/drivers/scsi/aic7xxx/aicasm/ |
| D | aicasm.c | 74 STAILQ_HEAD(patch_list, patch) patches;
126 STAILQ_INIT(&patches); in main()
425 for (cur_patch = STAILQ_FIRST(&patches); in output_code()
429 cur_patch == STAILQ_FIRST(&patches) ? "" : ",\n", in output_code()
493 pinfo = &scope->patches[patch]; in emit_patch()
515 STAILQ_INSERT_TAIL(&patches, new_patch, links); in emit_patch()
596 cur_patch = STAILQ_FIRST(&patches); in output_listing()
804 cur_scope->patches[1].skip_patch = in process_scope()
806 cur_scope->patches[1].skip_instr = in process_scope()
816 cur_scope->patches[0].skip_patch = patch0_patch_skip; in process_scope()
[all …]
|
| /Linux-v4.19/Documentation/acpi/ |
| D | linuxized-acpica.txt | 110 Linux patches. The patches generated by this process are referred to as
111 "linuxized ACPICA patches". The release process is carried out on a local
167 Before the linuxized ACPICA patches are sent to the Linux ACPI community
175 Ideally, all of the ACPICA commits should be converted into Linux patches
203 user space simulation utilities, thus the linuxized ACPICA patches may
206 linuxized ACPICA patches during the release process. When the release
219 utilities to obtain Linux patches corresponding to upstream ACPICA commits
243 top of the generated ACPICA release patches:
247 $ generate/linux/make-patches.sh -u [commit ID]
|
| /Linux-v4.19/Documentation/arm/SA1100/ |
| D | Brutus | 53 The actual Brutus support may not be complete without extra patches.
54 If such patches exist, they should be found from
63 Please send patches to nico@fluxnic.net
|
| /Linux-v4.19/Documentation/dev-tools/ |
| D | coccinelle.rst | 12 tree-wide patches and detection of problematic programming patterns.
17 The semantic patches included in the kernel use features and options
75 Note that not all semantic patches implement all modes. For easy use
93 To produce patches, run::
106 positives. Thus, reports must be carefully checked, and patches
170 about semantic patches displayed, and no commit message proposed.
179 Debugging Coccinelle SmPL patches
187 Alternatively you can debug running Coccinelle against SmPL patches
302 SmPL patches can have their own requirements for options passed
311 As Coccinelle features get added some more advanced SmPL patches
[all …]
|
| /Linux-v4.19/ |
| D | .gitignore | 98 patches-*
101 patches
|
| /Linux-v4.19/drivers/staging/erofs/ |
| D | TODO | 35 ask and send patches,
42 Cc: (for linux-kernel upstream patches)
|
| /Linux-v4.19/Documentation/devicetree/bindings/ |
| D | submitting-patches.txt | 2 Submitting devicetree (DT) binding patches
6 0) Normal patch submission rules from Documentation/process/submitting-patches.rst
10 be a separate patch. The preferred subject prefix for binding patches is:
|
| /Linux-v4.19/Documentation/virtual/kvm/ |
| D | review-checklist.txt | 1 Review checklist for kvm patches
5 Documentation/process/submitting-patches.rst.
|
| /Linux-v4.19/Documentation/ |
| D | SubmittingPatches | 1 This file has moved to process/submitting-patches.rst
|
| /Linux-v4.19/Documentation/scsi/ |
| D | lpfc.txt | 16 as of 2.6.12. We no longer need to provide patches for this support,
62 By default, the driver expects the patches for block/unblock interfaces
81 Thankfully, at this time, patches are not needed.
|
| /Linux-v4.19/drivers/usb/usbip/ |
| D | README | 7 Please send patches for this code to Greg Kroah-Hartman <greg@kroah.com>
|
| /Linux-v4.19/Documentation/translations/ko_KR/ |
| D | howto.rst | 117 …:ref:`Documentation/process/submitting-patches.rst <submittingpatches>` 와 :ref:`Documentation/proc…
173 :ref:`Documentation/process/applying-patches.rst <applying_patches>`
433 여러분들이 패치들을 메일에 넣는다면 그것들은 Documentation/process/submitting-patches.rst에
|
| /Linux-v4.19/drivers/staging/dgnc/ |
| D | TODO | 5 Please send patches to Greg Kroah-Hartman <greg@kroah.com> and
|
| /Linux-v4.19/Documentation/translations/ja_JP/ |
| D | SubmittingPatches | 2 This is a version of Documentation/process/submitting-patches.rst into Japanese.
18 linux-2.6.39/Documentation/process/submitting-patches.rst の和訳
713 Andi Kleen, "On submitting kernel patches"
715 http://halobates.de/on-submitting-patches.pdf
|
