Lines Matching refs:of
6 of conventions and procedures which are used in the posting of patches;
32 There are a number of things which should be done before you consider
35 - Test the code to the extent that you can. Make use of the kernel's
37 combinations of configuration options, use cross-compilers to build for
44 benchmarks showing what the impact (or benefit) of your change is; a
45 summary of the results should be included with the patch.
57 The preparation of patches for posting can be a surprising amount of work,
61 Patches must be prepared against a specific version of the kernel. As a
69 on the area of your patch and what is going on elsewhere, basing a patch
70 against these other trees can require a significant amount of work
74 everything else should be made as a logical series of changes. Splitting
75 up patches is a bit of an art; some developers spend a long time figuring
77 rules of thumb, however, which can help considerably:
79 - The patch series you post will almost certainly not be the series of
93 - As a way of restating the guideline above: do not mix different types of
101 working kernel. Partial application of a patch series is a common
104 users who are engaging in the noble work of tracking down problems.
106 - Do not overdo it, though. One developer once posted a set of edits
112 - It can be tempting to add a whole new infrastructure with a series of
121 which takes quite a bit of time and thought after the "real work" has been
127 So now you have a perfect series of patches for posting, but the work is
129 quickly and clearly communicates its purpose to the rest of the world. To
130 that end, each patch will be composed of the following:
132 - An optional "From" line naming the author of the patch. This line is
136 - A one-line description of what the patch does. This message should be
138 scope of the patch; it is the line that will show up in the "short form"
140 subsystem name first, followed by the purpose of the patch. For
145 - A blank line followed by a detailed description of the contents of the
150 the author of the patch. Tags will be described in more detail below.
155 bear in mind that a number of different people will be reading your words.
161 good changelog conveys the needed information to all of these people in the
164 To that end, the summary line should describe the effects of and motivation
174 general, the more you can put yourself into the shoes of everybody who will
191 been associated with the development of this patch. They are described in
193 summary. Each of these lines has the format:
201 agreement to the Developer's Certificate of Origin, the full text of
206 maintainer of the relevant code) that the patch is appropriate for
221 - Cc: the named person received a copy of the patch and had the
224 Be careful in the addition of tags to your patches: only Cc: is appropriate
225 for addition without the explicit permission of the person named.
230 Before you mail your patches, there are a couple of other things you should
231 take care of:
242 - Are you sure your patch is free of silly mistakes? You should always
245 embodiment of a fair amount of thought about what kernel patches should
250 attachments; that makes it much harder for reviewers to quote sections of
256 people to err on the side of sending too many copies; don't assume that the
260 - The maintainer(s) of the affected subsystem(s). As described earlier,
274 next stable update. If so, stable@vger.kernel.org should get a copy of
279 When selecting recipients for a patch, it is good to have an idea of who
283 subsystem maintainers who watch over specific parts of the kernel. Usually
285 obvious maintainer, Andrew Morton is often the patch target of last resort.
290 [PATCH nn/mm] subsys: one-line description of the patch
292 where "nn" is the ordinal number of the patch, "mm" is the total number of
293 patches in the series, and "subsys" is the name of the affected subsystem.
296 If you have a significant series of patches, it is customary to send an
302 In general, the second and following parts of a multi-part patch should be
304 receiving end. Tools like git and quilt have commands to mail out a set of