| /linux/Documentation/process/ |
| H A 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 (https://www.selenic.com/ketchup/).
241 Where can I download the patches?
[all …]
|
| H A 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
93 serious. For this reason, patches which cause regressions are looked upon
209 How patches get into the Kernel
212 There is exactly one person who can merge patches into the mainline kernel
213 repository: Linus Torvalds. But, for example, of the over 9,500 patches
231 maintainers to track a list of patches, including authorship information
233 patches in his or her repository are not found in the mainline.
236 the patches they have selected for merging from their repositories. If
[all …]
|
| H A D | stable-kernel-rules.rst | 6 Rules on what kind of patches are accepted, and which ones are not, into the
13 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
34 Procedure for submitting patches to the -stable tree
39 Security patches should not be handled (solely) by the -stable review
101 patches present in the series itself. For example, if you have the following
124 * Delay pick up of patches::
183 - When the -stable maintainers decide for a review cycle, the patches will be
191 - The ACKed patches will be posted again as part of release candidate (-rc)
194 issues, some patches may be modified or dropped or additional patches may
201 containing all the queued and tested patches.
[all …]
|
| H A D | contribution-maturity-model.rst | 19 take on upstream contributions such as reviewing other people’s patches,
40 * Software Engineers are not allowed to contribute patches to the Linux
47 * Software Engineers are allowed to contribute patches to the Linux
64 * Software Engineers are expected to review patches (including patches
92 time focused on Upstream Work, which is defined as reviewing patches,
|
| H A 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 …]
|
| H A D | howto.rst | 12 If anything in this document becomes out of date, please send in patches
104 patches if these rules are followed, and many people will only
107 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
115 Following these rules will not guarantee success (as all patches are
119 Other excellent descriptions of how to create patches properly are:
162 :ref:`Documentation/process/applying-patches.rst <applying_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
256 new kernel as rock solid as possible. Most of the patches at this point
263 patches to Linus after -rc1 is released, but the patches need to also be
[all …]
|
| H A 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.
88 that your patches go nowhere.
119 dedicated to patches planned for the next merge window, and another for
122 For patches applying to areas for which there is no obvious subsystem tree
123 (memory management patches, for example), the default tree often ends up
137 burner so that the remaining patches can be worked into shape and merged.
139 developers and, possibly, moving some patches between trees to ensure that
178 for; you can start creating cool new patches once any problems with the old
[all …]
|
| H A D | researcher-guidelines.rst | 74 To help clarify: sending patches to developers *is* interacting
76 contributions*. Sending intentionally flawed/vulnerable patches or
96 * Documentation/process/submitting-patches.rst
103 When sending patches produced from research, the commit logs should
158 (This is required if you have been explicitly told your patches need
164 resulting patches, and there by reduces the burden on other developers.
166 If no one can be found to internally review patches and you need
|
| H A D | maintainer-kvm-x86.rst | 67 room for the size of a series, patches that are "cache hot", etc. Fixes,
79 can, within reason, to ensure that your patches are ready to be merged! Pings
112 :ref:`maintainer-tip-coding-style`, as patches/series often touch both KVM and
200 approach! Please follow the tip tree's preferred style when sending patches
234 KVM x86 opts out of backporting Fixes: by default. Some auto-selected patches
245 At a bare minimum, *all* patches in a series must build cleanly for KVM_INTEL=m
252 negligible probability of affecting runtime behavior, e.g. patches that only
335 base tree information in the generated patches.
355 know that KVM-unit-tests is a separate repository and get confused when patches
356 in a series apply on different trees. To tie KVM-unit-tests patches back to
[all …]
|
| /linux/scripts/package/ |
| H A D | mkdebian | 107 mkdir -p debian/patches
115 } > debian/patches/config.patch
116 echo config.patch > debian/patches/series
118 "${srctree}/scripts/package/gen-diff-patch" debian/patches/diff.patch
119 if [ -s debian/patches/diff.patch ]; then
124 " debian/patches/diff.patch
126 echo diff.patch >> debian/patches/series
128 rm -f debian/patches/diff.patch
|
| /linux/Documentation/bpf/ |
| H A 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
10 Documentation/process/submitting-patches.rst. This document only describes
44 Submitting patches
49 A: BPF CI is GitHub based and hosted at https://github.com/kernel-patches/bpf.
53 The following steps lay out how to start a CI run for your patches:
59 or bpf branch, and apply your to-be-tested patches on top of it
62 kernel-patches/bpf's bpf-next_base or bpf_base branch, respectively
65 that capacity is shared with patches submitted upstream being checked and so
[all …]
|
| /linux/Documentation/livepatch/ |
| H A D | cumulative-patches.rst | 5 There might be dependencies between livepatches. If multiple patches need
7 an order in which the patches will be installed. And function implementations
10 This might become a maintenance nightmare. Especially when more patches
30 Once the transition is finished, all older patches are automatically
65 to reverse it and restore the replaced patches atomically.
78 executed. Any callbacks from the replaced patches are ignored.
83 As a result, it might be dangerous to replace newer cumulative patches by
93 enabled patches were called.
|
| /linux/drivers/scsi/aic7xxx/aicasm/ |
| H A 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/Documentation/maintainer/ |
| H A D | maintainer-entry-profile.rst | 7 (submitting-patches, submitting drivers...) with
18 tells the contributor where to send patches for which files, it does not
24 - Are there notifications when patches are applied to the local tree, or
47 require published specifications at a certain revision before patches
53 One of the common misunderstandings of submitters is that patches can be
55 considered for the next -rc1. The reality is that most patches need to
58 week) that patches might be considered for merging and when patches need to
|
| /linux/Documentation/arch/riscv/ |
| H A D | patch-acceptance.rst | 22 RISC-V has a patchwork instance, where the status of patches can be checked:
29 Automation runs against this patchwork instance, building/testing patches as
30 they arrive. The automation applies patches against the current HEAD of the
39 We'll only accept patches for new modules or extensions if the
52 RISC-V extensions, we'll only consider patches for extensions that either:
|
| /linux/Documentation/nvdimm/ |
| H A D | maintainer-entry-profile.rst | 15 In general patches can be submitted against the latest -rc; however, if
19 are cases where patches are more suitable to be merged through a
32 Those tests need to be passed before the patches go upstream, but not
38 Before patches enabling a new _DSM family will be considered, it must
52 and some patches may require multiple development cycles to review.
|
| /linux/Documentation/driver-api/acpi/ |
| H A D | linuxized-acpica.rst | 125 Linux patches. The patches generated by this process are referred to as
126 "linuxized ACPICA patches". The release process is carried out on a local
182 Before the linuxized ACPICA patches are sent to the Linux ACPI community
191 Ideally, all of the ACPICA commits should be converted into Linux patches
219 user space simulation utilities, thus the linuxized ACPICA patches may
222 linuxized ACPICA patches during the release process. When the release
236 utilities to obtain Linux patches corresponding to upstream ACPICA commits
260 top of the generated ACPICA release patches::
264 $ generate/linux/make-patches.sh -u [commit ID]
|
| /linux/Documentation/mm/damon/ |
| H A D | maintainer-profile.rst | 20 Sufficiently reviewed patches will be queued in `mm-unstable
22 subsystem maintainer. After more sufficient tests, the patches will be queued
26 Note again the patches for `mm-unstable tree
28 management subsystem maintainer. If the patches requires some patches in
65 Mon-Fri) in PT (Pacific Time). The response to patches will occasionally be
|
| /linux/scripts/ |
| H A D | git.orderFile | 3 # order file for git, to produce patches which are easier to review
34 # semantic patches
|
| /linux/Documentation/driver-api/media/ |
| H A D | maintainer-entry-profile.rst | 28 must be kept in sync with the API changes. It means that all patches that
35 task to review the patches, providing feedback to users if the patches are
122 Those tests need to pass before the patches go upstream.
134 Be sure to not introduce new warnings on your patches without a
158 In principle, patches should follow the coding style rules, but exceptions
196 Except for bug fixes, we don't usually add new patches to the development
200 could take a while for us to be able to review your patches. Feel free
|
| /linux/Documentation/translations/zh_CN/process/ |
| H A D | index.rst | 32 submitting-patches
91 * applying-patches
|
| /linux/Documentation/dev-tools/ |
| H A D | coccinelle.rst | 14 tree-wide patches and detection of problematic programming patterns.
19 The semantic patches included in the kernel use features and options
92 Note that not all semantic patches implement all modes. For easy use
110 To produce patches, run::
123 positives. Thus, reports must be carefully checked, and patches
194 about semantic patches displayed, and no commit message proposed.
203 Debugging Coccinelle SmPL patches
211 Alternatively you can debug running Coccinelle against SmPL patches
325 SmPL patches can have their own requirements for options passed
334 As Coccinelle features get added some more advanced SmPL patches
[all …]
|
| /linux/scripts/coccinelle/misc/ |
| H A D | minmax.cocci | 4 /// Generated patches sometimes require adding a cast to fix compile warning.
5 /// Warnings/patches scope intentionally limited to a function body.
|
| /linux/Documentation/virt/kvm/ |
| H A D | review-checklist.rst | 4 Review checklist for kvm patches
8 Documentation/process/submitting-patches.rst.
|
| /linux/Documentation/devicetree/bindings/ |
| H A D | submitting-patches.rst | 4 Submitting Devicetree (DT) binding patches
11 Documentation/process/submitting-patches.rst applies.
14 be a separate patch. The preferred subject prefix for binding patches is::
|