Skip to content

Kernel

The Hyperscale SIG maintains a kernel in the experimental repository. This kernel is based on the Fedora kernel with a RHEL-ish configuration and tries to follow it as closely as possible, while enabling additional features such as btrfs and Kernel Live Patching. In turn, the kernel is based on the upstream ARK sources, which is where the Fedora kernel and future RHEL kernels are developed and released.

The Hyperscale kernel is built for CentOS Stream 9 and eventually CentOS Stream 10 from the same sources (meaning, we effectively ship a backport of the Fedora kernel for CentOS Stream 9 and eventually CentOS Stream 10).

Contributing to the Hyperscale kernel

In general, the best way to contribute to the Hyperscale kernel build is to contribute to the upstream Linux kernel sources. This follows the Linux Kernel contribution process.

As a matter of policy, all of the patches we backport for the Hyperscale build of the kernel are first merged to cki-project/kernel-ark, which is the GitLab repo where the Fedora kernel is developed and maintained. This allows us to leverage the testing and maintenance by the Red Hat kernel teams and share efforts with the broader community that also contribute to the kernel.

We try to maintain as few patches as possible for each release, but we are open to including new features or bug fixes that are not yet available. We follow the practices documented by the RHEL kernel team.

Contributing to the ARK kernel sources

  • Get a Fedora account if you don't have one already.
    • Make sure to follow this part and set up your ~/.fedora.upn to tell our tooling your FAS username if it differs from your Unix name.
  • Get a GitLab.com account if you don't have one already.
    • Make sure your display name matches your actual name used in Git commits.
    • Make sure the email address you use for Git commits is attached to your GitLab.com account.
  • Set your GitLab.com account username in your Fedora account.
  • Set your Red Hat Bugzilla account and make sure your Fedora account email address matches your Bugzilla account email address.
  • Fork cki-project/kernel-ark.
  • In your local clone of your fork, add cki-project/kernel-ark as a remote by the name upstream.
  • In your local clone of your fork, add torvalds/linux as a remote by the name mainline.
  • Run git fetch --all to fetch all the refs from all the remotes.
  • Create a new branch based on upstream/os-build (next) or upstream/fedora-X.Y (current kernel series) for the patches to be applied.
    • For example, for branching from fedora-6.7, do: git checkout --no-track -b <branchname> upstream/fedora-6.7
  • Generate a list of commits to backport and use git-cherry-pick.
    • For example, for backporting zstd from v6.8 to v6.7, do: git rev-list --reverse v6.7..v6.8 -- lib/zstd | git cherry-pick -n --stdin
  • Push your branch to your fork on GitLab.com
  • Open a merge request (MR) against cki-project/kernel-ark with your change.
    • Tag @jforbes, @Conan_Kudo and @dcavalca to notify for reviews.
  • Once merged and the Fedora kernel folks make a release, one of the Hyperscale kernel maintainers will update the RPM spec and publish a new version of the kernel for Hyperscale with the patches included.

Building the ARK or Hyperscale kernels

The kernel package is maintained with the packaging data merged in with the source tree. This is commonly known as a "merged source" or "source-git" tree. Even so, the kernel package is special and requires a special process to build.

Being able to build the kernel is useful for testing patches you wish to contribute or if you want to make your own builds for personal use.

  • Once in the root of the tree and you've made your changes, generate the changelog commit using make dist-release-finish
    • For example, to make a build with 0.test.1 release, run make dist-release-finish DISTLOCALVERSION="0.test.1" SNAPSHOT="0" BUILD="0"
  • Generate the git tag using make dist-release-tag
    • For example, to make a build with 0.test.1 release, run make dist-release-tag DISTLOCALVERSION="0.test.1" SNAPSHOT="0" BUILD="0"
  • Generate the SRPM using make dist-srpm
    • For example, to make a SRPM with 0.test.1 release for CentOS Stream 9, run make dist-srpm DISTLOCALVERSION="0.test.1" SNAPSHOT=0 BUILD="0" DIST=".el9"

Once you have the generated SRPM, you can build it with mock like normal.

If you're building off the os-build branch (or a branch derived from it), you will want to drop SNAPSHOT="0" from the arguments passed to make.