openSUSE:Kernel git
Getting Started
First, install git, the newer the better. git-core-1.5.6 or newer is known to work, if you are using an older GIT and encounter problems, please report them (ideally with a patch attached) to opensuse-kernel@opensuse.org. If you do not encounter problems, please update the sentence about which minimum version is known to work.
Setting up a clone
git clone https://github.com/SUSE/kernel
This will create the master branch only, to set up further branches, do
git checkout -b $branch origin/$branch
and later just
git checkout $branch
Use git branch -r to see which branches exist. See also #Branch Names below.
Some people prefer to have a separate clone for each branch they work on. You can either copy the clone in this case, or clone again, but use the --reference option (assuming that kernel is a pre-existing clone):
git clone --reference kernel https://github.com/SUSE/kernel kernel-15.2
Note that if you are only working with one or a few branches in a clone, it is a good idea to delete the other branches and change the configuration to only fetch the branches you are interested in (by default, everything is fetched if you do a git pull).
git checkout -b openSUSE-15.2 origin/openSUSE-15.2 git branch -D master git config remote.origin.fetch +refs/heads/openSUSE-15.2:refs/remotes/origin/openSUSE-15.2
If you are going to commit anything, it is time to introduce yourself:
git config [--global] user.name "Your Name Comes Here" git config [--global] user.email your@email
Branch Names
The openSUSE kernel branches are named openSUSE-$version, e.g. openSUSE-42.3 or openSUSE-15.1. SLE branches use SLE${version} for the GA branches and SLE${version}-SP${number} for service packs. In the kernel-source repository, each branch also has a README.BRANCH file indicating the purpose of the branch.
An overview of active branches can be found on kernel.suse.com.
Please note: branches for products which reached EOL will be removed from the git repositories.
Get your current kernel config
The easiest way to get your current kernel config :
cp /boot/config-`uname -r` .config
Using the kernel-source repository
As already noted, development happens in the kernel-source repository. This repository also hosts the .config files and rpm spec files to build rpm packages. To clone it, run
git clone https://github.com/SUSE/kernel-source cd kernel-source scripts/install-git-hooks
The install-git-hooks script sets up a commit hook and other helpers, so that common mistakes are caught automatically. The layout of the repository is following
- config/$arch/$flavor: Config files
- patches.*/: Patches applied to the vanilla tree. patches.kernel.org and patches.rpmify are special in that these are also applied to the kernel-vanilla flavor.
- rpm/: Spec files and scripts that end up in the rpm package.
- kabi/: Kabi reference files.
- scripts/: Scripts for use inside the repository.
To generate a quilt tree so that you can add patches or update existing ones, run
scripts/sequence-patch.sh
This unpacks the vanilla linux tarball in the tmp/ subdirectory, applies the patch series and generates the necessary metadata for quilt. The refresh_patch.sh script should be used to refresh patches, so that they have a common format. Each kernel patch requires a header, see the README file for details. New patches need to be added to the series.conf file in the top-level directory. If you are backporting an upstream patch, put it in the sorted section of that file using git_sort (a set of scripts inside the SUSE kernel repository). When you are done, commit your changes with
scripts/log
This will launch an editor with a pre-generated changelog entry. If you are only adding patches, it is enough to use the changelog as is, otherwise expand it if needed and type :wq. Please use scripts/log when committing, so that the changelog has a unified format.
Refreshing other patches
After a patch is added somewhere in the middle of series.conf, some patches further down may have to be refreshed. This can be tiresome when adding a larger patch series. In this situation, you can:
- git tag base
- add all patches to series.conf
- ./scripts/log # without refreshing any other patch
- git rebase -i -x ~/bin/kseries_check base
- git tag -d base
The content of ~/bin/kseries_check is:
#!/bin/sh if hash rapidquilt 2> /dev/null ; then scripts/sequence-patch.sh -q --rapid --dry-run || exit 1 else scripts/sequence-patch.sh -q --fast > /dev/null 2>&1 || exit 1 fi
It will drop you in a shell whenever a patch needs to be refreshed. Do the refresh and then run:
- git reset HEAD^
- ./scripts/log
- git rebase --continue
Building kernel packages
scripts/tar-up.sh
This creates a source package in the kernel-source subdirectory. You can use rpmbuild to build a kernel RPM, or if you have a Build Service account, use the osc_wrapper script:
scripts/osc_wrapper # local build scripts/osc_wrapper kernel-source/kernel-debug.spec # locally build a flavor other than "default" scripts/osc_wrapper upload home:$login:kernel # remote build
Submitting your changes to the kernel team
Please remember that the recommended way to have a patch included in the openSUSE kernel is to push it upstream (Linus' tree for master, v5.x.y for released products). If you want to change something in the packaging, scripts or config files, send your patches to
- kernel@lists.opensuse.org - .
Subscribe - Unsubscribe - Help - Archives