Searched full:patch (Results 1 – 25 of 235) sorted by relevance
12345678910
| /Documentation/process/ |
| D | applying-patches.rst | 11 This document is obsolete. In most cases, rather than using ``patch``
15 a patch to the kernel or, more specifically, what base kernel a patch for
24 What is a patch?
27 A patch is a small text document containing a delta of changes between two
31 To correctly apply a patch you need to know what base it was generated from
32 and what new version the patch will change the source tree into. These
33 should both be present in the patch file metadata or be possible to deduce
37 How do I apply or revert a patch?
40 You apply a patch with the ``patch`` program. The patch program reads a diff
41 (or patch) file and makes the changes to the source tree described in it.
[all …]
|
| D | submitting-patches.rst | 48 Describe your problem. Whether your patch is a one-line bug fix or
77 The maintainer will thank you if you write your patch description in a
81 Solve only one problem per patch. If your description starts to get
82 long, that's a sign that you probably need to split up your patch.
85 When you submit or resubmit a patch or patch series, include the
86 complete patch description and justification for it. Don't just
87 say that this is version N of the patch (series). Don't expect the
88 subsystem maintainer to refer back to earlier patch versions or referenced
89 URLs to find the patch description and put that into the patch.
90 I.e., the patch (series) and its description should be self-contained.
[all …]
|
| D | 5.Posting.rst | 50 summary of the results should be included with the patch.
60 Patch preparation
68 general rule, a patch should be based on the current mainline as found in
75 on the area of your patch and what is going on elsewhere, basing a patch
79 Only the most simple changes should be formatted as a single patch;
85 - The patch series you post will almost certainly not be the series of
93 patch. These changes can be small ("add a field to this structure") or
95 conceptually small and amenable to a one-line description. Each patch
100 changes in the same patch. If a single patch fixes a critical security
105 - Each patch should yield a kernel which builds and runs properly; if your
[all …]
|
| D | backporting.rst | 27 Applying the patch to a tree
30 Sometimes the patch you are backporting already exists as a git commit,
32 ``git cherry-pick``. However, if the patch comes from an email, as it
37 quite picky about the patch applying perfectly to your source tree. In
39 edit the patch to make it apply.
42 where the patch applies cleanly and *then* cherry-pick it over to your
46 apply a patch that just arrived on LKML to an older stable kernel, you
50 It's generally better to use the exact same base as the one the patch
53 problem with applying the patch to the "wrong" base is that it may pull
60 it less likely to apply the patch to the wrong place (which can result
[all …]
|
| D | stable-kernel-rules.rst | 45 1. Add a 'stable tag' to the description of a patch you then submit for
47 2. Ask the stable team to pick up a patch already mainlined.
48 3. Submit a patch to the stable team that is equivalent to a change already
56 options for cases where a mainlined patch needs adjustments to apply in older
70 To have a patch you submit for mainline inclusion later automatically picked up
79 Once the patch is mainlined it will be applied to the stable tree without
85 * Specify any additional patch prerequisites for cherry picking::
100 Note that for a patch series, you do not have to list as prerequisites the
102 patch series::
130 Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3
[all …]
|
| D | 6.Followthrough.rst | 13 It is a rare patch which is so good at its first posting that there is no
25 A patch of any significance will result in a number of comments from other
31 - If you have explained your patch well, reviewers will understand its
64 from happening. When you get review comments on a patch, take the time to
93 raised issues and how you dealt with them; the patch changelog is a good
114 If a patch is considered to be a good thing to add to the kernel, and once
128 patch. Now other developers working with that tree will get the patch by
134 What may also happen at this point, depending on the nature of your patch,
136 case, heavy patch conflicts can result in some work being put on the back
145 Some day, if all goes well, you'll log on and see that your patch has been
[all …]
|
| D | maintainer-netdev.rst | 12 - designate your patch to a tree - ``[PATCH net]`` or ``[PATCH net-next]``
61 git trees and patch flow
89 (use ``--subject-prefix='RFC net-next'`` with ``git format-patch``).
108 netdev patch review
113 Patch status
116 Status of a patch can be checked by looking at the main patchwork
122 patch:
125 Patch state Description
127 New, Under review pending review, patch is in the maintainer’s queue for
130 Accepted patch was applied to the appropriate networking tree, this is
[all …]
|
| D | email-clients.rst | 13 If you are new to ``git`` then send your first patch to yourself. Save it
16 the patch to the appropriate mailing list(s).
25 it makes quoting portions of the patch more difficult in the patch
34 patch text untouched. For example, they should not modify or delete tabs
41 This can also corrupt your patch.
60 It's a good idea to send a patch to yourself, save the received message,
61 and successfully apply it with 'patch' before sending patches to Linux
88 When composing the message, the cursor should be placed where the patch
89 should appear, and then pressing :kbd:`CTRL-R` let you specify the patch file
97 To insert a patch use :menuselection:`Message-->Insert File` (:kbd:`CTRL-I`)
[all …]
|
| /Documentation/translations/it_IT/process/ |
| D | 5.Posting.rst | 15 e di procedure per la pubblicazione delle patch; seguirle renderà la vita
26 C'è sempre una certa resistenza nel pubblicare patch finché non sono
27 veramente "pronte". Per semplici patch questo non è un problema.
37 Poche persone guarderanno delle patch che si sa essere fatte a metà,
42 Prima di creare patch
46 l'invio delle patch alla comunità di sviluppo. Queste cose includono:
56 - La vostra patch ha delle conseguenze in termini di prestazioni?
59 incluso nella patch.
70 Preparazione di una patch
73 La preparazione delle patch per la pubblicazione può richiedere una quantità
[all …]
|
| D | submitting-patches.rst | 8 Inviare patch: la guida essenziale per vedere il vostro codice nel kernel
11 Una persona o un'azienda che volesse inviare una patch al kernel potrebbe
15 vostre patch accettate.
22 Per delle patch relative alle associazioni per Device Tree leggete
25 Questa documentazione assume che sappiate usare ``git`` per preparare le patch.
44 sorgenti e desiderano che le patch siano preparate basandosi su di essi.
66 singolarmente le patch dai sorgenti principali; quindi, includete tutte
87 I manutentori vi saranno grati se scrivete la descrizione della patch in un
91 Risolvete solo un problema per patch. Se la vostra descrizione inizia ad
92 essere lunga, potrebbe essere un segno che la vostra patch necessita d'essere
[all …]
|
| D | stable-kernel-rules.rst | 11 Regole sul tipo di patch che vengono o non vengono accettate nei sorgenti
14 - Questa patch o una equivalente deve esistere già nei sorgenti principali di
40 Procedura per sottomettere patch per i sorgenti -stable
44 Una patch di sicurezza non dovrebbe essere gestita (solamente) dal processo
50 1. Aggiungi un'etichetta 'stable' alla descrizione della patch al momento della
52 2. Chiedere alla squadra "stable" di prendere una patch già applicata sui
54 3. Sottomettere una patch alla squadra "stable" equivalente ad una modifica già
62 L':ref:`it_option_3` è un'alternativa ai due metodi precedenti quando la patch
79 Aggiungete la seguente etichetta nell'area delle firme per far sì che una patch
91 Una volta che la patch è stata inclusa, verrà applicata anche sui sorgenti
[all …]
|
| D | email-clients.rst | 17 per applicare le patch.
19 Se siete dei novelli utilizzatori di ``git`` allora inviate la patch a voi
23 la patch alla lista di discussione più appropriata.
28 Le patch per il kernel vengono inviate per posta elettronica, preferibilmente
32 ben apprezzati perché rende più difficile citare porzioni di patch durante il
36 messaggio, sia per la patch che per qualsiasi altro messaggio. Il sito
40 I programmi di posta elettronica che vengono usati per inviare le patch per il
45 Non inviate patch con ``format=flowed``. Questo potrebbe introdurre
49 Questo può corrompere le patch.
52 testo. Le patch inviate per posta elettronica dovrebbero essere codificate in
[all …]
|
| D | submit-checklist.rst | 8 Lista delle verifiche da fare prima di inviare una patch per il kernel Linux
12 vedere le proprie patch accettate più rapidamente.
15 sottomissione delle patch, in particolare
41 5) Controllate lo stile del codice della vostra patch secondo le direttive
43 Prima dell'invio della patch, usate il verificatore di stile
46 vostra patch.
55 8) La patch è stata accuratamente revisionata rispetto alle più importanti
74 12) La patch è stata verificata con le seguenti opzioni abilitate
80 13) La patch è stata compilata e verificata in esecuzione con, e senza,
83 14) Se la patch ha effetti sull'IO dei dischi, eccetera: allora dev'essere
[all …]
|
| D | 2.Process.rst | 42 patch di ogni rilascio. All'inizio di ogni ciclo di sviluppo, la
46 patch per un nuovo ciclo di sviluppo (e tutte le più importanti modifiche)
48 1000 modifiche ("patch" o "gruppo di modifiche") al giorno.
150 Il ciclo di vita di una patch
153 Le patch non passano direttamente dalla tastiera dello sviluppatori
155 per assicurare che ogni patch sia di buona qualità e desiderata nel
157 meno importanti, o, nel caso di patch ampie e controverse, va avanti per anni.
162 come una patch viene inserita nel kernel. Ciò che segue è un'introduzione
166 Una patch attraversa, generalmente, le seguenti fasi:
174 - Prima revisione. Le patch vengono pubblicate sulle liste di discussione
[all …]
|
| D | 7.AdvancedTopics.rst | 44 La prima cosa da fare prima di usarlo per produrre patch che saranno
56 Utilizzare git per produrre patch da sottomettere via email può essere
73 essere creati con attenzione; integrate patch dai rami di sviluppo
79 o fatta sparire completamente dalla storia. Una serie di patch può essere
84 di patch pulite e con meno problemi.
88 perfetta. Riscrivere la storia riscriverà le patch contenute in quella
97 Dunque, una volta che il vostro insieme di patch è stato reso disponibile
99 questa regola, e si rifiuterà di pubblicare nuove patch che non risultino
101 patch che non condividono la stessa storia). È possibile ignorare questo
103 un ramo già pubblicato. Un esempio è linux-next dove le patch vengono
[all …]
|
| /Documentation/livepatch/ |
| D | callbacks.rst | 5 Livepatch (un)patch-callbacks provide a mechanism for livepatch modules
16 In most cases, (un)patch callbacks will need to be used in conjunction
26 patch.
39 * Pre-patch
42 * Post-patch
48 active), used to clean up post-patch callback
54 used to cleanup pre-patch callback resources
61 symmetry: pre-patch callbacks have a post-unpatch counterpart and
62 post-patch callbacks have a pre-unpatch counterpart. An unpatch
63 callback will only be executed if its corresponding patch callback was
[all …]
|
| D | cumulative-patches.rst | 23 static struct klp_patch patch = {
29 All processes are then migrated to use the code only from the new patch.
34 longer modified by the new cumulative patch.
37 cumulative patch. It helps to keep the patch consistent while adding or
40 Users could keep only the last patch installed on the system after
52 - Atomically revert some functions in a previous patch while
69 to that patch. This is safe as long as the livepatches do _not_ do
73 Also note that the replaced patch can be removed and loaded again
80 In other words, the cumulative patch is responsible for doing any actions
81 that are necessary to properly replace any older patch.
[all …]
|
| D | livepatch.rst | 46 a live patch is called with the help of a custom ftrace handler. But there are
64 But there are more complex fixes. For example, a patch might change
65 ordering of locking in multiple functions at the same time. Or a patch
84 switch over. When a patch is enabled, livepatch enters into a
87 sequence occurs when a patch is disabled, except the tasks converge from
95 safe to patch tasks:
99 the task is patched. In most cases this will patch most or all of
128 Unless we can come up with another way to patch kthreads, architectures
132 The /sys/kernel/livepatch/<patch>/transition file shows whether a patch
133 is in transition. Only a single patch can be in transition at a given
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-kernel-livepatch | 9 each loaded live patch module.
11 What: /sys/kernel/livepatch/<patch>
16 The patch directory contains subdirectories for each kernel
19 What: /sys/kernel/livepatch/<patch>/enabled
25 code is currently applied. Writing 0 will disable the patch
26 while writing 1 will re-enable the patch.
28 What: /sys/kernel/livepatch/<patch>/transition
33 An attribute which indicates whether the patch is currently in
36 What: /sys/kernel/livepatch/<patch>/force
45 use this feature without a clearance from a patch
[all …]
|
| /Documentation/translations/it_IT/arch/riscv/ |
| D | patch-acceptance.rst | 3 :Original: :doc:`../../../../arch/riscv/patch-acceptance`
28 RISC-V ha un'istanza di patchwork dov'è possibile controllare lo stato delle patch:
32 Se la vostra patch non appare nella vista predefinita, i manutentori di RISC-V
37 e collaudando le patch man mano che arrivano. Il processo applica le patch al
39 questo a seconda che la patch sia stata o meno individuata come correzione. In
41 stata applicata una serie di patch sarà annotato su patchwork. È improbabile che
42 vengano applicate Le patch che non passano i controlli, nella maggior parte dei
45 In aggiunta alla lista delle verifiche da fare prima di inviare una patch
48 Accetteremo le patch per un nuovo modulo o estensione se la fondazione
57 prestazioni, accetteremo patch solo per quelle estensioni che sono
|
| /Documentation/dev-tools/ |
| D | coccinelle.rst | 67 For Semantic Patch Language(SmPL) grammar documentation refer to:
78 Four basic modes are defined: ``patch``, ``report``, ``context``, and
82 - ``patch`` proposes a fix, when possible.
106 To make a report for every semantic patch, run the following command::
112 make coccicheck MODE=patch
115 The coccicheck target applies every semantic patch available in the
118 For each semantic patch, a commit message is proposed. It gives a
119 description of the problem being checked by the semantic patch, and
151 Using Coccinelle with a single semantic patch
155 semantic patch. In that case, the variable must be initialized with
[all …]
|
| /Documentation/devicetree/bindings/ |
| D | submitting-patches.rst | 7 I. For patch submitters
10 0) Normal patch submission rules from
13 1) The Documentation/ and include/dt-bindings/ portion of the patch should
14 be a separate patch. The preferred subject prefix for binding patches is::
46 5) The Documentation/ portion of the patch should come in the series before
79 3) For a series going though multiple trees, the binding patch should be
90 devicetree maintainers overrules this document. In that situation, a patch
|
| /Documentation/translations/zh_TW/process/ |
| D | submitting-patches.rst | 86 用祈使句描述你的變更，例如“make xyzzy do frotz”而不是“[This patch]make
173 在提交之前，使用補丁樣式檢查程序檢查補丁（scripts/check patch.pl）。不過，
264 問題。當發送下一版時，在封面郵件或獨立補丁里加上 ``patch changelog`` 說明與
281 [PATCH Vx RESEND] sub/sys: Condensed patch summary
286 主題中包含 PATCH
289 由於到Linus和linux-kernel的電子郵件流量很高，通常會在主題行前面加上[PATCH]
454 可以使用 ``git format-patch`` 進行正確的補丁格式化。但是，這些工具無法創建
459 Subject: [PATCH 001/123] 子系統:一句話概述
495 概述的前綴可以用方括號括起來：“Subject: [PATCH <tag>...] <概述>”。標記
504 Subject: [patch 2/5] ext2: improve scalability of bitmap searching
[all …]
|
| /Documentation/translations/zh_CN/process/ |
| D | submitting-patches.rst | 85 用祈使句描述你的变更，例如“make xyzzy do frotz”而不是“[This patch]make
172 在提交之前，使用补丁样式检查程序检查补丁（scripts/check patch.pl）。不过，
263 问题。当发送下一版时，在封面邮件或独立补丁里加上 ``patch changelog`` 说明与
280 [PATCH Vx RESEND] sub/sys: Condensed patch summary
285 主题中包含 PATCH
288 由于到Linus和linux-kernel的电子邮件流量很高，通常会在主题行前面加上[PATCH]
453 可以使用 ``git format-patch`` 进行正确的补丁格式化。但是，这些工具无法创建
458 Subject: [PATCH 001/123] 子系统:一句话概述
494 概述的前缀可以用方括号括起来：“Subject: [PATCH <tag>...] <概述>”。标记
503 Subject: [patch 2/5] ext2: improve scalability of bitmap searching
[all …]
|
| /Documentation/hwmon/ |
| D | submitting-patches.rst | 1 How to Get Your Patch Accepted Into the Hwmon Subsystem
18 * Please run your patch through 'checkpatch --strict'. There should be no
26 * If your patch generates checkpatch errors, warnings, or check messages,
32 * Please test your patch thoroughly. We are not your test group.
33 Sometimes a patch can not or not completely be tested because of missing
36 explicitly below the patch header.
38 * If your patch (or the driver) is affected by configuration options such as
51 your patch into a cleanup part and the actual addition. This makes it easier
54 * Never mix bug fixes, cleanup, and functional enhancements in a single patch.
60 * Running your patch or driver file(s) through checkpatch does not mean its
|
12345678910