Lines Matching full:a
8 kernel. Unsurprisingly, the kernel development community has evolved a set
21 There is a constant temptation to avoid posting patches before they are
22 completely "ready." For simple patches, that is not a problem. If the
23 work being done is complex, though, there is a lot to be gained by getting
25 consider posting in-progress work, or even making a git tree available so
28 When posting code which is not yet considered ready for inclusion, it is a
38 There are a number of things which should be done before you consider
50 benchmarks showing what the impact (or benefit) of your change is; a
54 for an employer, the employer likely has a right to the work and must be
57 As a general rule, putting in some extra thought before posting code almost
64 The preparation of patches for posting can be a surprising amount of work,
68 Patches must be prepared against a specific version of the kernel. As a
69 general rule, a patch should be based on the current mainline as found in
70 Linus's git tree. When basing on mainline, start with a well-known release
71 point - a stable or -rc release - rather than branching off the mainline at
74 It may become necessary to make versions against -mm, linux-next, or a
76 on the area of your patch and what is going on elsewhere, basing a patch
77 against these other trees can require a significant amount of work
80 Only the most simple changes should be formatted as a single patch;
81 everything else should be made as a logical series of changes. Splitting
82 up patches is a bit of an art; some developers spend a long time figuring
83 out how to do it in the way that the community expects. There are a few
93 - Each logically independent change should be formatted as a separate
94 patch. These changes can be small ("add a field to this structure") or
95 large (adding a significant new driver, for example), but they should be
96 conceptually small and amenable to a one-line description. Each patch
97 should make a specific change which can be reviewed on its own and
100 - As a way of restating the guideline above: do not mix different types of
101 changes in the same patch. If a single patch fixes a critical security
102 bug, rearranges a few structures, and reformats the code, there is a
106 - Each patch should yield a kernel which builds and runs properly; if your
107 patch series is interrupted in the middle, the result should still be a
108 working kernel. Partial application of a patch series is a common
110 result is a broken kernel, you will make life harder for developers and
113 - Do not overdo it, though. One developer once posted a set of edits
114 to a single file as 500 separate patches - an act which did not make him
115 the most popular person on the kernel mailing list. A single patch can
116 be reasonably large as long as it still contains a single *logical*
119 - It can be tempting to add a whole new infrastructure with a series of
124 the real bug is elsewhere. Whenever possible, a patch which adds new
127 Working to create the perfect patch series can be a frustrating process
128 which takes quite a bit of time and thought after the "real work" has been
135 So now you have a perfect series of patches for posting, but the work is
136 not done quite yet. Each patch needs to be formatted into a message which
144 - A one-line description of what the patch does. This message should be
145 enough for a reader who sees it with no other context to figure out the
155 - A blank line followed by a detailed description of the contents of the
159 - One or more tag lines, with, at a minimum, one Signed-off-by: line from
163 changelogs is a crucial but often-neglected art; it's worth spending
164 another moment discussing this issue. When writing a changelog, you should
165 bear in mind that a number of different people will be reading your words.
168 trying to decide whether a patch should be backported to other kernels, bug
169 hunters wondering whether the patch is responsible for a problem they are
170 chasing, users who want to know how the kernel has changed, and more. A
177 needed additional information. If the patch fixes a bug, cite the commit
179 and the title when citing commits). If a problem is associated with
181 searching for a solution to the same problem. If the change is meant to
185 be reading your changelog, the better that changelog (and the kernel as a
189 change to a revision control system. It will be followed by:
204 document; what follows here is a brief summary. Each of these lines has
213 - Signed-off-by: this is a developer's certification that he or she has
217 Code without a proper signoff cannot be merged into the mainline.
220 it is a used to give attribution to co-authors (in addition to the author
221 attributed by the From: tag) when multiple people work on a single patch.
222 Every Co-developed-by: must be immediately followed by a Signed-off-by: of
226 - Acked-by: indicates an agreement by another developer (often a
237 - Reported-by: names a user who reported a problem which is fixed by this
242 - Cc: the named person received a copy of the patch and had the
252 Before you mail your patches, there are a couple of other things you should
267 embodiment of a fair amount of thought about what kernel patches should
268 look like, is not smarter than you. If fixing a checkpatch.pl complaint
289 - If you are responding to a bug report or a feature request, copy the
292 - Send a copy to the relevant mailing list, or, if nothing else applies,
295 - If you are fixing a bug, think about whether the fix should go into the
296 next stable update. If so, stable@vger.kernel.org should get a copy of
297 the patch. Also add a "Cc: stable@vger.kernel.org" to the tags within
298 the patch itself; that will cause the stable team to get a notification
301 When selecting recipients for a patch, it is good to have an idea of who
309 Patches need good subject lines. The canonical format for a patch line is
318 Clearly, nn/mm can be omitted for a single, standalone patch.
320 If you have a significant series of patches, it is customary to send an
326 In general, the second and following parts of a multi-part patch should be
327 sent as a reply to the first part so that they all thread together at the
328 receiving end. Tools like git and quilt have commands to mail out a set of
329 patches with the proper threading. If you have a long series, though, and