| /kernel/linux/linux-5.10/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 | 43 Describe your problem. Whether your patch is a one-line bug fix or
72 The maintainer will thank you if you write your patch description in a
76 Solve only one problem per patch. If your description starts to get
77 long, that's a sign that you probably need to split up your patch.
80 When you submit or resubmit a patch or patch series, include the
81 complete patch description and justification for it. Don't just
82 say that this is version N of the patch (series). Don't expect the
83 subsystem maintainer to refer back to earlier patch versions or referenced
84 URLs to find the patch description and put that into the patch.
85 I.e., the patch (series) and its description should be self-contained.
[all …]
|
| D | 5.Posting.rst | 51 summary of the results should be included with the patch.
61 Patch preparation
69 general rule, a patch should be based on the current mainline as found in
76 on the area of your patch and what is going on elsewhere, basing a patch
80 Only the most simple changes should be formatted as a single patch;
86 - The patch series you post will almost certainly not be the series of
94 patch. These changes can be small ("add a field to this structure") or
96 conceptually small and amenable to a one-line description. Each patch
101 changes in the same patch. If a single patch fixes a critical security
106 - Each patch should yield a kernel which builds and runs properly; if your
[all …]
|
| /kernel/linux/linux-4.19/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 | 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
[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 …]
|
| /kernel/linux/linux-4.19/kernel/livepatch/ |
| D | core.c | 36 #include "patch.h"
75 * Note that the patch might still be needed before klp_module_going() in klp_find_object_module()
86 static bool klp_is_patch_registered(struct klp_patch *patch) in klp_is_patch_registered() argument
91 if (mypatch == patch) in klp_is_patch_registered()
282 static int __klp_disable_patch(struct klp_patch *patch) in __klp_disable_patch() argument
286 if (WARN_ON(!patch->enabled)) in __klp_disable_patch()
292 /* enforce stacking: only the last enabled patch can be disabled */ in __klp_disable_patch()
293 if (!list_is_last(&patch->list, &klp_patches) && in __klp_disable_patch()
294 list_next_entry(patch, list)->enabled) in __klp_disable_patch()
297 klp_init_transition(patch, KLP_UNPATCHED); in __klp_disable_patch()
[all …]
|
| /kernel/linux/linux-5.10/Documentation/translations/it_IT/process/ |
| D | 5.Posting.rst | 15 e di procedure per la pubblicazione delle patch; seguirle renderà la vita
27 C'è sempre una certa resistenza nel pubblicare patch finché non sono
28 veramente "pronte". Per semplici patch questo non è un problema.
38 Poche persone guarderanno delle patch che si sa essere fatte a metà,
43 Prima di creare patch
47 l'invio delle patch alla comunità di sviluppo. Queste cose includono:
57 - La vostra patch ha delle conseguenze in termini di prestazioni?
60 incluso nella patch.
71 Preparazione di una patch
74 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.
23 per delle patch relative alle associazioni per Device Tree leggete
28 patch molto del lavoro più ripetitivo lo troverete già fatto per voi, tuttavia
29 dovete preparare e documentare un certo numero di patch. Generalmente, l'uso
43 sorgenti e desiderano che le patch siano preparate basandosi su di essi.
55 Se dovete produrre le vostre patch a mano, usate ``diff -up`` o ``diff -uprN``
56 per crearle. Git produce di base le patch in questo formato; se state
59 Tutte le modifiche al kernel Linux avvengono mediate patch, come descritte
[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
35 I programmi di posta elettronica che vengono usati per inviare le patch per il
40 Non inviate patch con ``format=flowed``. Questo potrebbe introdurre
44 Questo può corrompere le patch.
47 testo. Le patch inviate per posta elettronica dovrebbero essere codificate in
55 Di solito, il copia-e-incolla (o taglia-e-incolla) non funziona con le patch
[all …]
|
| D | stable-kernel-rules.rst | 11 Regole sul tipo di patch che vengono o non vengono accettate nei sorgenti
37 - Questa patch o una equivalente deve esistere già nei sorgenti principali di
41 Procedura per sottomettere patch per i sorgenti -stable
44 - Se la patch contiene modifiche a dei file nelle cartelle net/ o drivers/net,
47 ma solo dopo aver verificato al seguente indirizzo che la patch non sia
50 - Una patch di sicurezza non dovrebbero essere gestite (solamente) dal processo
63 Per far sì che una patch venga automaticamente inclusa nei sorgenti stabili,
70 nell'area dedicata alla firme. Una volta che la patch è stata inclusa, verrà
79 Dopo che la patch è stata inclusa nei sorgenti Linux, inviate una mail a
80 stable@vger.kernel.org includendo: il titolo della patch, l'identificativo
[all …]
|
| /kernel/linux/linux-5.10/kernel/livepatch/ |
| D | core.c | 24 #include "patch.h"
69 * Note that the patch might still be needed before klp_module_going() in klp_find_object_module()
100 static struct klp_object *klp_find_object(struct klp_patch *patch, in klp_find_object() argument
105 klp_for_each_object(patch, obj) { in klp_find_object()
324 * /sys/kernel/livepatch/<patch>
325 * /sys/kernel/livepatch/<patch>/enabled
326 * /sys/kernel/livepatch/<patch>/transition
327 * /sys/kernel/livepatch/<patch>/force
328 * /sys/kernel/livepatch/<patch>/<object>
329 * /sys/kernel/livepatch/<patch>/<object>/<function,sympos>
[all …]
|
| D | state.c | 15 #define klp_for_each_state(patch, state) \ argument
16 for (state = patch->states; state && state->id; state++)
20 * the given patch
21 * @patch: livepatch that modifies the given system state
24 * Checks whether the given patch modifies the given system state.
26 * The function can be called either from pre/post (un)patch
31 struct klp_state *klp_get_state(struct klp_patch *patch, unsigned long id) in klp_get_state() argument
35 klp_for_each_state(patch, state) { in klp_get_state()
58 * It is typically called only from pre/post (un)patch
66 struct klp_patch *patch; in klp_get_prev_state() local
[all …]
|
| /kernel/linux/linux-5.10/scripts/ |
| D | patch-kernel | 4 # usage: patch-kernel [ sourcedir [ patchdir [ stopversion ] [ -acxx ] ] ]
5 # The source directory defaults to /usr/src/linux, and the patch
8 # scripts/patch-kernel . ..
11 # scripts/patch-kernel . .. -ac
12 # Get the latest Linux kernel and patch it with the latest ac patch
13 # scripts/patch-kernel . .. 2.4.9
15 # scripts/patch-kernel . .. 2.4.9 -ac
17 # scripts/patch-kernel . .. 2.4.9 -ac11
18 # Gets 2.4.9 with ac patch ac11
23 # It then looks for patches for the next sublevel in the patch directory.
[all …]
|
| /kernel/linux/linux-4.19/scripts/ |
| D | patch-kernel | 4 # usage: patch-kernel [ sourcedir [ patchdir [ stopversion ] [ -acxx ] ] ]
5 # The source directory defaults to /usr/src/linux, and the patch
8 # scripts/patch-kernel . ..
11 # scripts/patch-kernel . .. -ac
12 # Get the latest Linux kernel and patch it with the latest ac patch
13 # scripts/patch-kernel . .. 2.4.9
15 # scripts/patch-kernel . .. 2.4.9 -ac
17 # scripts/patch-kernel . .. 2.4.9 -ac11
18 # Gets 2.4.9 with ac patch ac11
23 # It then looks for patches for the next sublevel in the patch directory.
[all …]
|
| /kernel/linux/linux-5.10/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 …]
|
| /kernel/linux/linux-4.19/Documentation/livepatch/ |
| D | callbacks.txt | 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
23 patch.
33 * Pre-patch - before a klp_object is patched
35 * Post-patch - after a klp_object has been patched and is active
39 active), used to clean up post-patch callback
44 used to cleanup pre-patch callback resources
48 symmetry: pre-patch callbacks have a post-unpatch counterpart and
49 post-patch callbacks have a pre-unpatch counterpart. An unpatch
50 callback will only be executed if its corresponding patch callback was
[all …]
|
| D | livepatch.txt | 59 a live patch is called with the help of a custom ftrace handler. But there are
77 But there are more complex fixes. For example, a patch might change
78 ordering of locking in multiple functions at the same time. Or a patch
97 switch over. When a patch is enabled, livepatch enters into a
100 sequence occurs when a patch is disabled, except the tasks converge from
108 safe to patch tasks:
112 the task is patched. In most cases this will patch most or all of
141 Unless we can come up with another way to patch kthreads, architectures
145 The /sys/kernel/livepatch/<patch>/transition file shows whether a patch
146 is in transition. Only a single patch (the topmost patch on the stack)
[all …]
|
| /kernel/linux/linux-5.10/tools/testing/selftests/livepatch/ |
| D | test-callbacks.sh | 20 # pre-patch callbacks are executed for vmlinux and $MOD_TARGET (those
22 # according to the klp_patch, their post-patch callbacks run and the
25 # - Similarly, on livepatch disable, pre-patch callbacks run before the
26 # unpatching transition starts. klp_objects are reverted, post-patch
40 livepatch: enabling patch '$MOD_LIVEPATCH'
67 # - On livepatch enable, only pre/post-patch callbacks are executed for
71 # pre/post-patch callbacks are executed.
85 livepatch: enabling patch '$MOD_LIVEPATCH'
93 livepatch: applying patch '$MOD_LIVEPATCH' to loading module '$MOD_TARGET'
135 livepatch: enabling patch '$MOD_LIVEPATCH'
[all …]
|
| /kernel/linux/linux-5.10/sound/drivers/opl3/ |
| D | opl3_synth.c | 216 * Patch management
231 * load a patch, obviously.
236 * name is the name string of the patch.
247 struct fm_patch *patch; in snd_opl3_load_patch() local
250 patch = snd_opl3_find_patch(opl3, prog, bank, 1); in snd_opl3_load_patch()
251 if (!patch) in snd_opl3_load_patch()
254 patch->type = type; in snd_opl3_load_patch()
257 patch->inst.op[i].am_vib = data[AM_VIB + i]; in snd_opl3_load_patch()
258 patch->inst.op[i].ksl_level = data[KSL_LEVEL + i]; in snd_opl3_load_patch()
259 patch->inst.op[i].attack_decay = data[ATTACK_DECAY + i]; in snd_opl3_load_patch()
[all …]
|
| /kernel/linux/linux-4.19/sound/drivers/opl3/ |
| D | opl3_synth.c | 230 * Patch management
245 * load a patch, obviously.
250 * name is the name string of the patch.
261 struct fm_patch *patch; in snd_opl3_load_patch() local
264 patch = snd_opl3_find_patch(opl3, prog, bank, 1); in snd_opl3_load_patch()
265 if (!patch) in snd_opl3_load_patch()
268 patch->type = type; in snd_opl3_load_patch()
271 patch->inst.op[i].am_vib = data[AM_VIB + i]; in snd_opl3_load_patch()
272 patch->inst.op[i].ksl_level = data[KSL_LEVEL + i]; in snd_opl3_load_patch()
273 patch->inst.op[i].attack_decay = data[ATTACK_DECAY + i]; in snd_opl3_load_patch()
[all …]
|
| /kernel/linux/linux-4.19/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>/signal
48 What: /sys/kernel/livepatch/<patch>/force
[all …]
|
| /kernel/linux/linux-5.10/arch/xtensa/kernel/ |
| D | jump_label.c | 26 struct patch { struct
41 struct patch *patch = data; in patch_text_stop_machine() argument
43 if (atomic_inc_return(&patch->cpu_count) == 1) { in patch_text_stop_machine()
44 local_patch_text(patch->addr, patch->data, patch->sz); in patch_text_stop_machine()
45 atomic_inc(&patch->cpu_count); in patch_text_stop_machine()
47 while (atomic_read(&patch->cpu_count) <= num_online_cpus()) in patch_text_stop_machine()
49 __invalidate_icache_range(patch->addr, patch->sz); in patch_text_stop_machine()
57 struct patch patch = { in patch_text() local
64 &patch, NULL); in patch_text()
|
| /kernel/linux/linux-5.10/ |
| D | README | 17 You should test your patch in OpenHamrony supported boards, hi3516dv300,
22 should use git-format-patch to generate patches, and if it's a patchset,
28 And make sure your patch follow unified OpenHarmony patch format describe
37 3. Send patch to OpenHarmony mailing list
40 git send-email *.patch -to="kernel@openharmony.io" --suppress-cc=all
52 4. Mark "v1, v2, v3 ..." in your patch subject if you have multiple versions
55 Use --subject-prefix="PATCH v2" option to add v2 tag for patchset.
56 git format-patch --subject-prefix="PATCH v2" -1
59 Subject: [PATCH v2 01/27] fork: fix some -Wmissing-prototypes warnings
60 Subject: [PATCH v3] ext2: improve scalability of bitmap searching
[all …]
|
| /kernel/linux/linux-4.19/ |
| D | README | 17 You should test your patch in OpenHamrony supported boards, hi3516dv300,
22 should use git-format-patch to generate patches, and if it's a patchset,
28 And make sure your patch follow unified OpenHarmony patch format describe
37 3. Send patch to OpenHarmony mailing list
40 git send-email *.patch -to="kernel@openharmony.io" --suppress-cc=all
52 4. Mark "v1, v2, v3 ..." in your patch subject if you have multiple versions
55 Use --subject-prefix="PATCH v2" option to add v2 tag for patchset.
56 git format-patch --subject-prefix="PATCH v2" -1
59 Subject: [PATCH v2 01/27] fork: fix some -Wmissing-prototypes warnings
60 Subject: [PATCH v3] ext2: improve scalability of bitmap searching
[all …]
|