Kernel Repository Guidelines
============================
Table Of Contents
=================
Patch Headers
Before You Commit -- Things To Check
Config Option Changes
Committing and Log Messages
What Is The Kernel ABI?
Kernel ABI Changes
Embargoed Patches
Related Information
Patch Headers
=============
Each patch must have a RFC822-style header that at a minimum describes
what the patch does, who wrote it, and who inside SUSE/Novell we'll
"blame" about problems with the patch. The rules for patch headers are:
* Each patch must have a From: tag that identifies the author of the
patch.
* Each patch must have a Subject: tag that briefly describes what
the patch does. A brief summary is it could show up in a change
log makes the most sense in most cases.
* Unless the author identified in the From: tag has a @suse.de,
@suse.com, @suse.cz, or @novell.com address, the patch must include
a Signed-off-by: or Acked-by: header which identifies the person
in one of these domains who feels responsible for the patch inside
the company.
* The patch should include a Patch-mainline: tag that identifies where
the patch came from (for backports from mainline), or when it is
expected to be added to mainline.
* The patch should include a References: tag that identifies the
Bugzilla bug number, FATE entry, etc. where the patch is discussed.
* The patch header may (and often, should) include a more extensive
description of what the patch does, why, and how. The idea is to
allow others to quickly identify what each patch is about, and to
give enough information for reviewing.
More details about valid patch headers can be found in
scripts/patch-tag-template. The helper script scripts/patch-tag can be
used for managing these tags. Documentation for patch-tag can be found
at the top of the script itself.
Example usage of scripts/patch-tag-template:
$ cp scripts/patch-tag-template ~/.patchtag
Edit ~/.patchtag with any default values you want
$ patch-tag -e file.diff
Example patch header:
| From: Andrew Morton <akpm@osdl.org>
| Subject: Fix EOF -EIO problems with direct io
| References: 47120, LTC1001
| Patch-mainline: 2.6.11-rc2
|
| For reasons which escape me, blockdev_get_blocks() is returning -EIO if
| the mapping request straddles the end of the disk. This causes reads
| which straddle end-of-disk to return -EIO.
|
| Fix it up so that it correctly trims the returned result down to match
| the size of the device, for both reads and writes.
|
| If a write attempt is fully beyond end-of-device then return -EIO. We
| never get this far anyway, because generic_write_checks() will return
| -ENOSPC if all of the write lies outside a blockdev's i_size.
|
| Signed-off-by: Jens Axboe <axboe@suse.de>
Before You Commit -- Things To Check
====================================
Make sure that all patches still apply after your changes. One way of
doing this is using scripts/sequence-patch.sh:
$ export SCRATCH_AREA=/var/tmp/scratch
$ scripts/sequence-patch.sh
Please subscribe to the kernel-cvs@suse.de mailing list,
http://mailman.suse.de/mailman/listinfo/kernel-cvs. This is where
automatic build failures are sent; please watch this list
particularly after committing to the repository.
Please test-compile the kernel or even test-build kernel packages,
depending on the impact of your changes. Use scripts/tar-up.sh for
creating an Autobuild source directory.
The kernel source tree that scripts/sequence-patch.sh creates can be
test compiled as follows:
$ cp config/i386/default $SCRATCH_AREA/linux-2.6.18
$ cd $SCRATCH_AREA/linux-2.6.18
$ make oldconfig
$ make
Config Option Changes
=====================
We are building kernel packages for various architectures and
configurations from the same sources. Each such kernel has its own
configuration file in config/$ARCH/$FLAVOR. There are checks in place
that abort the kernel build when those configuration files are missing
config options.
When adding patches that add kernel config options, please also update
all config files as follows:
$ scripts/sequence-patch.sh
$ cd /var/tmp/scratch/linux-2.6.16
$ patches/scripts/run_oldconfig.sh
Committing and Log Messages
===========================
Any commit which affects the kernel package (rather than internals of the
repository such as helper scripts) should be documented in
kernel-source.changes. The log entry must include the timestamp
(`date`), email address of the committer, and a change summary, and
should include the names of the affected files, as in the following
example:
| -------------------------------------------------------------------
| Wed Dec 1 18:29:44 CET 2004 - agruen@suse.de
|
| - patches.fixes/serialize-dgram-read.diff: Serialize dgram read
| using semaphore just like stream (#48427).
|
There is a simple helper script for creating changelog entries in this
format (/work/src/bin/vc).
An advanced script (scripts/log) for creating changelog entries from
patch headers, and then automatically committing the change, exists as
well. This script extracts Subject: and References: headers from added
or modified patches and generates a changelog entry proposal that the
user can further modify. This approach works well for new or removed
patches. When modifying existing patches, it usually is necessary to
modify the generated changelog entry by hand. (scripts/log requires the
vc helper script either in the PATH, or in /work/src/bin/).
What Is The Kernel ABI?
=======================
All symbols that the kernel exports for use by modules, and all symbols
that modules export for use by other modules, are associated with a
so-called modversion, which is a checksum of the type of the symbol
(including all sub-types involved). Symbols that a module imports are
associated with the identical checksum.
When a module is loaded, the kernel makes sure that the checksums of the
exported symbols match the checksums of the imported symbols.
The kernel exports a large number of symbols (in the range of 5000). We
could Provide and Require all those symbols as RPM package dependencies,
so that then those dependencies would make sure that all packages
containing kernel modules would have a matching kernel installed.
RPM does not easily handle such large amounts of dependencies though,
and so instead of modeling dependencies based on individual symbols, we
compute distinct classes of symbols, and we create one "kernel(...)"
RPM dependency per class.
Modifying, adding, or removing kernel exports will also change the
kernel(...) symbols.
Kernel ABI Changes
==================
During kernel builds, two things related to the kernel ABI happen:
* If a reference symvers file (/boot/symvers-* in kernel-$FLAVOR
packages) for the particular architecture and flavor is available, we
check how severe the ABI changes are compared to this reference.
These reference files are located in kabi/$ARCH/symvers-$FLAVOR. Too
severe changes will abort the build. See rpm/kernel-binary.spec.in
and scripts/kabi-checks for details.
* We want to avoid losing kernel(...) symbols when additional symbols
are added, but all previous symbols are still available: in this
case, all modules will continue to load into the new kernel just
fine.
If a reference symsets file (/boot/symsets-* in kernel-$FLAVOR
packages) for the particular architecture and flavor is available, we
check which of the symbol sets in the reference file can still be
exported, even though symbols have meanwhile been added. We also
export the kernel(...) symbols from reference symset files.
Updating Kernel ABI Reference Files
-----------------------------------
The kernel repository contains scripts/update-symvers, which can be run
on a set of RPM packages in order to extract the /boot/symvers-* and
/boot/symsets-* files from those RPMs, and add them to the repository
in the right places.
A rough guide to updating the Kernel ABI:
$ mbuild -r `mbuild -q | awk '{print $1}'` # remove all exiting mbuilds
$ cd kernel-source
$ ./scripts/tar-up_and_run_mbuild.sh -i all # all configs ignoring KABI
$ sleep 2h # wait for builds to complete
$ find /mounts/built/mbuild/$HOSTNAME-$USER-* -name *.rpm |\
xargs ./scripts/update-symvers
We need to update the reference files after each public kernel release
that includes kernel ABI changes.
Ignoring Kernel ABI Changes
---------------------------
Sometimes we want to tolerate particular kernel ABI changes (and not
abort the builds). At the same time, we do not want to update the
reference symvers and symsets files, because we still want to monitor the
relative changes, and we want to continue preserving all symbol sets
which are still compatible.
Particular kernel can be marked so that kernel ABI changes are ignored.
This is done by creating kabi/$ARCH/ignore-$FLAVOR files (e.g.,
kabi/x86_64/ignore-xen, kabi/s390/ignore-default). The kernel ABI checks
will still be produced, but the build will not be aborted. The file
contents d not matter.
All kernel ABI changes in all kernel packages can be ignored by creating
a file called IGNORE-KABI-BADNESS in the kernel-source/ sub-directory of
the repository that scripts/tar-up.sh creates. (This may be necessary
for PTF kernels occasionally.)
Embargoed Patches
=================
At certain times during development, the kernel may include "embargoed"
patches, i.e., patches that must not be mad available to parties outside
of SUSE/Novell before an agreed-upon time. Such patches usually have a
date of publication that has been coordinated among linux distributors,
etc.
We allow adding such patches to the repository, but the following must
be obeyed:
* The kernel-source.changes file should not give away details that
might allow someone to exploit the bug being fixed. (The automatic
CVS builds are made available publicaly, and the openSUSE copies of
the kernel packages also include the entire changelog.)
* Embargoed patches must be added to the embargoed-patches file with
their planned release date, so that automatic CVS builds will
automatically exclude them. When the release date shifts,
embargoed-patches must be updated accordingly.
Related Information
===================
https://wiki.innerweb.novell.com/index.php/SUSE/Labs_Publications/Kernel_Building.html
https://wiki.innerweb.novell.com/index.php/SUSE/Labs_Publications/kernel_patches_rules