Merge branch 'scripts' into SLE11-SP2
[opensuse:kernel-source.git] / README
1 Kernel Repository Guidelines
2 ============================
3
4
5 Table Of Contents
6 =================
7
8     Getting Started
9     Patch Headers
10     Before You Commit -- Things To Check
11     Config Option Changes
12     Committing and Log Messages
13     What Is The Kernel ABI?
14     Kernel ABI Changes
15     Embargoed Patches
16     Related Information
17
18 Getting Started
19 ===============
20
21 Make sure you have a decent git version (1.5.x should work) and quilt
22 installed.
23
24 Introduce yourself if you haven't done so already:
25     $ git config --global user.name "Your Name"
26     $ git config --global user.email your@email
27
28 If you ommit the --global option, the setting will only apply to this
29 clone.
30
31 Set up some git hooks and helpers:
32
33     $ ./scripts/install-git-hooks
34
35 To hack on the kernel sources:
36
37     $ ./scripts/sequence-patch.sh --quilt
38     $ cd tmp/linux-$version-$branch
39     $ quilt new patches.fixes/fix-foo-and-bar
40     $ quilt edit some/file.c
41     $ ./refresh_patch.sh
42     $ quilt header -e # see next chapter
43
44 Refer to quilt documentation for details. When you are done, add the new
45 patch to an appropriate place in the series.conf file and run
46 ./scripts/log to commit it.
47
48 To build rpm packages:
49
50     $ ./scripts/tar-up.sh
51
52 This creates a source package in the kernel-source directory. Use
53 'build', 'osc build' or upload it to the buildservice to build rpms.
54
55
56 Patch Headers
57 =============
58
59 Each patch must have a RFC822-style header that at a minimum describes
60 what the patch does, who wrote it, and who inside SUSE/Novell we'll
61 "blame" about problems with the patch.  The rules for patch headers are:
62
63  * Each patch must have a From: tag that identifies the author of the
64    patch.
65
66  * Each patch must have a Subject: tag that briefly describes what
67    the patch does.  A brief summary is it could show up in a change
68    log makes the most sense in most cases.
69
70  * Unless the author identified in the From: tag has a @suse.de,
71    @suse.com, @suse.cz, or @novell.com address, the patch must include
72    a Signed-off-by: or Acked-by: header which identifies the person
73    in one of these domains who feels responsible for the patch inside
74    the company.
75
76  * The patch must include a Patch-mainline: tag that identifies where
77    the patch came from (for backports from mainline), or when it is
78    expected to be added to mainline. The format is one of:
79
80    For backports from mainline:
81         Patch-mainline: <upstream version, ex. "v3.5-rc1">
82         Git-commit: <git hash>
83
84    If the commit is from a maintainer repository or some other
85    repository that isn't Linus's:
86         Patch-mainline: Queued in subsystem maintainer repository
87         Git-repo: <url>
88         Git-commit: <git hash>
89
90    If the patch is not upstream, depending on the situation:
91         Patch-mainline: Submitted, <timestamp - destination>
92
93         Patch-mainline: Not yet, <reason>
94
95         Patch-mainline: Never, <reason>
96
97  * The patch should include a References: tag that identifies the 
98    Bugzilla bug number, FATE entry, etc. where the patch is discussed.
99    Please prefix bugzilla.novell.com bug numbers with bnc# and fate
100    feature numbers with fate#. Have a look at
101    http://en.opensuse.org/Packaging/Patches#Current_set_of_abbreviations
102    for a full list of abbreviations.
103  
104  * The patch header may (and often, should) include a more extensive
105    description of what the patch does, why, and how.  The idea is to
106    allow others to quickly identify what each patch is about, and to
107    give enough information for reviewing.
108
109 More details about valid patch headers can be found in
110 scripts/patch-tag-template.  The helper script scripts/patch-tag can be
111 used for managing these tags.  Documentation for patch-tag can be found
112 at the top of the script itself.
113
114 Example usage of scripts/patch-tag-template:
115
116     $ cp scripts/patch-tag-template ~/.patchtag
117
118     Edit ~/.patchtag with any default values you want
119
120     $ patch-tag -e file.diff
121
122 Example patch header:
123
124     | Date: Fri, Sep 26 2008 15:20:10 +1000
125     | From: Peter Leckie <pleckie@sgi.com>
126     | References: SGI:PV986789 bnc#482148
127     | Subject: Clean up dquot pincount code
128     | Patch-mainline: 2.6.28
129     | 
130     | Clean up dquot pincount code.
131     | 
132     | This is a code cleanup and optimization that removes a per mount point
133     | spinlock from the quota code and cleans up the code.
134     | 
135     | The patch changes the pincount from being an int protected by a spinlock
136     | to an atomic_t allowing the pincount to be manipulated without holding
137     | the spinlock.
138     | 
139     | This cleanup also protects against random wakup's of both the aild and
140     | xfssyncd by reevaluating the pincount after been woken. Two latter patches
141     | will address the Spurious wakeups.
142     | 
143     | Signed-off-by: Peter Leckie <pleckie@sgi.com>
144     | Acked-by: Jan Kara <jack@suse.cz>
145
146 Before You Commit -- Things To Check
147 ====================================
148
149 Make sure that all patches still apply after your changes.  One way of
150 doing this is using scripts/sequence-patch.sh:
151
152     $ export SCRATCH_AREA=/var/tmp/scratch
153     $ scripts/sequence-patch.sh
154
155 Please test-compile the kernel or even test-build kernel packages,
156 depending on the impact of your changes.  Use scripts/tar-up.sh for
157 creating an Autobuild source directory.
158
159 The kernel source tree that scripts/sequence-patch.sh creates can be
160 test compiled as follows:
161
162     $ cp config/i386/default $SCRATCH_AREA/linux-2.6.18
163     $ cd $SCRATCH_AREA/linux-2.6.18
164     $ make oldconfig
165     $ make
166
167
168 Config Option Changes
169 =====================
170
171 We are building kernel packages for various architectures and
172 configurations from the same sources.  Each such kernel has its own
173 configuration file in config/$ARCH/$FLAVOR.  There are checks in place
174 that abort the kernel build when those configuration files are missing
175 config options.
176
177 When adding patches that add kernel config options, please also update
178 all config files as follows:
179
180     $ scripts/sequence-patch.sh
181     $ cd /var/tmp/scratch/linux-2.6.16
182     $ patches/scripts/run_oldconfig.sh
183
184
185 Committing and Log Messages
186 ===========================
187
188 Any commit which affects the kernel package (rather than internals of the
189 repository such as helper scripts) should be documented in
190 kernel-source.changes.  The log entry must include the timestamp
191 (`date`), email address of the committer, and a change summary, and
192 should include the names of the affected files, as in the following
193 example:
194
195     | -------------------------------------------------------------------
196     | Wed Dec  1 18:29:44 CET 2004 - agruen@suse.de
197     | 
198     | - patches.fixes/serialize-dgram-read.diff: Serialize dgram read
199     |   using semaphore just like stream (#48427).
200     | 
201
202 There is a simple helper script for creating changelog entries in this
203 format (/work/src/bin/vc).
204
205 An advanced script (scripts/log) for creating changelog entries from
206 patch headers, and then automatically committing the change, exists as
207 well.  This script extracts Subject: and References: headers from added
208 or modified patches and generates a changelog entry proposal that the
209 user can further modify.  This approach works well for new or removed
210 patches.  When modifying existing patches, it usually is necessary to
211 modify the generated changelog entry by hand.  (scripts/log requires the
212 vc helper script either in the PATH, or in /work/src/bin/).
213
214
215 What Is The Kernel ABI?
216 =======================
217
218 All symbols that the kernel exports for use by modules, and all symbols
219 that modules export for use by other modules, are associated with a
220 so-called modversion, which is a checksum of the type of the symbol
221 (including all sub-types involved).  Symbols that a module imports are
222 associated with the identical checksum.
223
224 When a module is loaded, the kernel makes sure that the checksums of the
225 exported symbols match the checksums of the imported symbols.
226
227 The kernel exports a large number of symbols (in the range of 5000).  We
228 could Provide and Require all those symbols as RPM package dependencies,
229 so that then those dependencies would make sure that all packages
230 containing kernel modules would have a matching kernel installed.
231
232 RPM does not easily handle such large amounts of dependencies though,
233 and so instead of modeling dependencies based on individual symbols, we
234 compute distinct classes of symbols, and we create one "kernel(...)"
235 RPM dependency per class.
236
237 Modifying, adding, or removing kernel exports will also change the
238 kernel(...) symbols.
239
240
241 Kernel ABI Changes
242 ==================
243
244 During kernel builds, two things related to the kernel ABI happen:
245
246  * If a reference symvers file (/boot/symvers-* in kernel-$FLAVOR
247    packages) for the particular architecture and flavor is available, we
248    check how severe the ABI changes are compared to this reference.
249    These reference files are located in kabi/$ARCH/symvers-$FLAVOR.  Too
250    severe changes will abort the build.  See rpm/kernel-binary.spec.in
251    and scripts/kabi-checks (SLES9 - SLES10) or rpm/symsets.pl (SLES11)
252    for details.
253
254  * We want to avoid losing kernel(...) symbols when additional symbols
255    are added, but all previous symbols are still available: in this
256    case, all modules will continue to load into the new kernel just
257    fine.
258    
259    If a reference symsets file (/boot/symsets-* in kernel-$FLAVOR
260    packages) for the particular architecture and flavor is available, we
261    check which of the symbol sets in the reference file can still be
262    exported, even though symbols have meanwhile been added.  We also
263    export the kernel(...) symbols from reference symset files.
264
265
266 To update the reference files, use scripts/update-symvers:
267
268     $ ./scripts/update-symvers kernel-default-2.6.27.25-0.1.1.x86_64.rpm \
269          kernel-default-2.6.27.25-0.1.1.i586.rpm ...
270
271 It is also possible to update only a subset of the symbols, e.g.:
272
273     $ ./scripts/update-symvers --filter=fs/xfs ...
274
275 In either case, ask the branch owner and kernel packager for permission
276 before touching the kabi files.
277
278
279
280 Ignoring Kernel ABI Changes
281 ---------------------------
282
283 Sometimes we want to tolerate particular kernel ABI changes (and not
284 abort the builds).  At the same time, we do not want to update the
285 reference symvers and symsets files, because we still want to monitor the
286 relative changes, and we want to continue preserving all symbol sets
287 which are still compatible.
288
289 Particular kernel can be marked so that kernel ABI changes are ignored.
290 This is done by creating kabi/$ARCH/ignore-$FLAVOR files (e.g.,
291 kabi/x86_64/ignore-xen, kabi/s390/ignore-default).  The kernel ABI checks
292 will still be produced, but the build will not be aborted.  The file
293 contents d not matter.
294
295 All kernel ABI changes in all kernel packages can be ignored by creating
296 a file called IGNORE-KABI-BADNESS in the kernel-source/ sub-directory of
297 the repository that scripts/tar-up.sh creates.  (This may be necessary
298 for PTF kernels occasionally.)
299
300
301 Embargoed Patches
302 =================
303
304 At certain times during development, the kernel may include "embargoed"
305 patches, i.e., patches that must not be mad available to parties outside
306 of SUSE/Novell before an agreed-upon time.  Such patches usually have a
307 date of publication that has been coordinated among linux distributors,
308 etc. Such patches must not be committed to the usual branches, because
309 these are pushed to a public mirror, but instead to a branch named with
310 an _EMBARGO suffix, e.g. SLE11_BRANCH_EMBARGO. The KOTD scripts will
311 testbuild such branches, but won't publish them. Once the fix becomes
312 public, the branch needs to be merged back info the "mainline" branch,
313 e.g.:
314
315     $ git checkout SLE11_BRANCH
316     $ git merge SLE11_BRANCH_EMBARGO
317
318
319 Related Information
320 ===================
321
322 Internal:
323 https://wiki.innerweb.novell.com/index.php/SUSE/Labs_Publications/Kernel_Building.html
324 https://wiki.innerweb.novell.com/index.php/SUSE/Labs_Publications/kernel_patches_rules
325
326 Public:
327 TBD