Kernel Repository Guidelines
============================


Table Of Contents
=================

    Getting Started
    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

Getting Started
===============

Make sure you have the git and quilt tools installed.

Introduce yourself if you haven't done so already:

    $ git config --global user.name "Your Name"
    $ git config --global user.email your@email

If you omit the --global option, the setting will only apply to this
repository clone.

Set up some Git hooks and helpers:

    $ ./scripts/install-git-hooks

To hack on the kernel sources:

    $ ./scripts/sequence-patch.sh
    $ cd tmp/linux-$version-$branch
    $ quilt new patches.suse/fix-foo-and-bar.patch
    $ quilt edit some/file.c
    $ ./refresh_patch.sh
    $ quilt header -e # see next chapter

Refer to the Quilt documentation for details. When you are done, add the new
patch to an appropriate place in the series.conf file and run
./scripts/log to commit it. Patches should be named such that they
consist of alphanumeric characters, '-' and '.'. Typically, patches are
named by filtering the Subject of the patch to a lower-case, dash-separated
form like the one in the example above.

To build RPM packages:

    $ ./scripts/tar-up.sh

This creates a source package in the kernel-source directory. Use

    $ ./scripts/osc_wrapper [kernel-source/kernel-$flavor.spec]

to build a kernel package locally, or

    $ ./scripts/osc_wrapper upload [--ibs]

to have all flavors and architectures built by the Open Build Service.
The --ibs option uses the SUSE internal instance.


Patch Headers
=============

Each patch must have an RFC822-style header that at a minimum describes
what the patch does, who wrote it and who inside SUSE can be
contacted 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 that could appear in a change
   log makes the most sense in most cases.

 * Unless the author specified in the From tag has a @suse.de,
   @suse.com or @suse.cz address, the patch must include a Signed-off-by,
   Acked-by or Reviewed-by header which identifies the person in one of
   these domains who feels responsible for the patch inside the company.

 * The patch must 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 format is one of:

   For backports from mainline:
        Patch-mainline: <upstream version, for instance, "v6.5-rc7">
        Git-commit: <git hash>

   If the commit is from a maintainer repository or some other
   repository that isn't Linus's:
        Patch-mainline: Queued in subsystem maintainer repository
        Git-repo: <url>
        Git-commit: <git hash>

   If the patch is not upstream, depending on the situation:
        Patch-mainline: Submitted, <timestamp - destination>

        Patch-mainline: Not yet, <reason>

        Patch-mainline: Never, <reason>

 * The patch should include a References tag that identifies the Bugzilla bug
   number, JIRA issue ID, etc. where the patch is discussed.  Please prefix
   bugzilla.suse.com bug numbers with bsc# and JIRA issue IDs with jsc#.
   Please make sure you specify a JIRA Implementation task when referencing
   JIRA features, not its Epic ID.  Have a look at
   https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines#Current_set_of_abbreviations
   for a full list of abbreviations.

 * The patch header 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: Pablo Neira Ayuso <pablo@netfilter.org>
    | Date: Tue, 15 Aug 2023 15:39:01 +0200
    | Subject: netfilter: nf_tables: GC transaction race with netns dismantle
    | Patch-mainline: v6.5-rc7
    | Git-commit: 02c6c24402bf1c1e986899c14ba22a10b510916b
    | References: CVE-2023-4563 bsc#1214727
    |
    | Use maybe_get_net() since GC workqueue might race with netns exit path.
    |
    | Fixes: 5f68718b34a5 ("netfilter: nf_tables: GC transaction API to avoid race with control plane")
    | Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    | Signed-off-by: Florian Westphal <fw@strlen.de>
    | Acked-by: Michal Kubecek <mkubecek@suse.cz>

Patch sorting
=============

Patches added to the "sorted patches" section of series.conf must be sorted
according to the upstream order of the commit that they backport.

After you've added a patch file to the main patches.suse/ or a different patch directory, and supplemented the
required tags described in the section "Patch Headers", run

    $ ./scripts/git_sort/series_insert.py <patch>

to insert an entry for a new patch file to the sorted section of series.conf.

For more information, please read "scripts/git_sort/README.md".

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
    Creating tree in /var/tmp/scratch/linux-5.14-SLE15-SP5
    Cleaning up from previous run
    Linking from /var/tmp/scratch/linux-5.14.orig
    ...
    [ Tree: /var/tmp/scratch/linux-5.14-SLE15-SP5 ]
    [ Generating Module.supported ]
    [ Copying config/x86_64/default ]

Note the "Tree:" line output by the sequence-patch.sh script which
specifies the location of the expanded kernel tree that is configured
for local build.
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 OBS package directory.

The kernel source tree that scripts/sequence-patch.sh creates can be
test-compiled. Before that, make sure all prerequisites are installed.
These include libopenssl-devel, libelf-devel and dwarves. Have a look into
rpm/kernel-binary.spec.in for a complete list. Then, the compilation
can be done as follows:

    $ cd /var/tmp/scratch/linux-5.14-SLE15-SP5
    $ make oldconfig
    $ make

When committing a patch series, try to make the series easily bisectable.
In other words, when applying only the first x patches (1 <= x <= n, n being the
number of patches in the series), the kernel should be still buildable and
functional.

This means especially that just adding upstream patches unmodified
to a series and doing a cleanup patch at the end of the series to
ensure the kernel is buildable and functional is to be avoided. Each
patch from upstream should be modified as required to fit into the
kernel it is backported to, both for build time and runtime.

Applying all patches in the tree with scripts/sequence-patch.sh can take
a significant amount of time. The --rapid option is present to speed up the
process and tells the script to use Rapidquilt instead of the regular Quilt.
The Rapidquilt implementation applies patches in parallel and typically produces
an expanded tree in a fraction of the original time. A Rapidquilt package can be
obtained from https://download.opensuse.org/repositories/Kernel:/tools/.

Config Option Changes
=====================

SUSE kernel packages for various architectures and
configurations are built from the same sources.  Each such kernel has its own
configuration file in config/$ARCH/$FLAVOR.  Checks are in place
that abort the kernel build when those configuration files are missing
necessary config options.

When adding patches that introduce new kernel config options, please also update
all config files as follows:

    $ scripts/sequence-patch.sh
    $ cd /var/tmp/scratch/linux-5.14-SLE15-SP5
    $ patches/scripts/run_oldconfig.sh


Committing and Log Messages
===========================

Every commit to the kernel source repository should be properly documented.
Tool scripts/tar-up.sh obtains change descriptions from a Git commit log and
automatically produces .changes files for use by the target RPM packages. All
commits which affect the kernel package have their description collected, only
changes modifying internals of the repository such as helper scripts are
skipped.

When recording your changes to the repository, you should use scripts/log rather
than running 'git commit' directly in order to produce a commit description in
the expected format.


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. It 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
symbols imported by the module match the checksums of the target symbols.
In case of a mismatch, the kernel rejects to load the module.

Kernel packages additionally set an RPM dependency in the form
"ksym($FLAVOR:$SYMBOL) = $CHECKSUM" for every exported/imported symbol.
A Provides dependency is present for each symbol exported by kernel binaries in
the package and a Requires dependency is recorded for each imported symbol. This
mechanism allows checking module dependencies early at the package installation
time.


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 (SLES9 - SLES10) or rpm/symsets.pl (SLES11)
   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.


To update the reference files, use scripts/update-symvers:

    $ ./scripts/update-symvers kernel-default-2.6.27.25-0.1.1.x86_64.rpm \
         kernel-default-2.6.27.25-0.1.1.i586.rpm ...

It is also possible to update only a subset of the symbols, e.g.:

    $ ./scripts/update-symvers --filter=fs/xfs ...

In either case, ask the branch owner and kernel packager for permission
before touching the kabi files.



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 before an agreed-upon time.  Such patches usually have a
date of publication that has been coordinated among linux distributors,
etc. Such patches must not be committed to the usual branches, because
these are pushed to a public mirror, but instead to a branch named with
an _EMBARGO suffix, e.g. SLE11_BRANCH_EMBARGO. The KOTD scripts will
testbuild such branches, but won't publish them. Once the fix becomes
public, the branch needs to be merged back info the "mainline" branch,
e.g.:

    $ git checkout SLE11_BRANCH
    $ git merge SLE11_BRANCH_EMBARGO


Related Information
===================

Internal:
https://wiki.suse.net/index.php/SUSE-Labs_Publications/Kernel_Building
https://wiki.suse.net/index.php/SUSE-Labs_Publications/kernel_patches_rules

Public:
TBD