RHEL Kernel Taxonomy

A shared vocabulary for the RHEL kernel family, covering terminology, lineage, and kernel types.

Audience: RHEL kernel developers and stakeholders across engineering and business.

Scope: Fedora, ARK, ELN, and RHEL.

Kernel Families

Fedora

Fedora Linux is a secure, general-purpose, and open-source operating system sponsored by Red Hat. It serves as a community-driven, cutting-edge platform for developers and users, focusing on innovation, rapid software updates, and new technologies like GNOME and Wayland. It is known for being the upstream foundation for Red Hat Enterprise Linux (RHEL).

ARK

ARK (Always Ready Kernel) is a shared tree hosted at https://gitlab.com/cki-project/kernel-ark/. It tracks Linus' tree and adds Red Hat packaging and configuration. ARK serves as the common base for both Fedora and ELN, carrying config files for Fedora as well as future RHEL. ARK rebases when Linus releases a new kernel version. The ARK process is documented at https://cki-project.gitlab.io/kernel-ark/.

While Linus' tree is upstream for the kernel source, ARK is the upstream for Red Hat-specific packaging and configs.

ELN

ELN (Enterprise Linux Next) is a bleeding-edge preview built directly from ARK using RHEL-targeted configurations. It serves as an internal early preview and staging ground, allowing Red Hat to validate that the ARK codebase and configurations are on track for the next major RHEL release. ELN is not a product offering; it is a testing and development signal.

RHEL

Red Hat Enterprise Linux (RHEL) is a secure, stable, and high-performance open-source operating system designed for enterprise environments, including servers, cloud computing, and datacenters.

For each major RHEL release, a dedicated tree is forked from ARK and developed publicly as a centos-stream kernel at https://gitlab.com/redhat/centos-stream/src/kernel/. There is one repository per major RHEL release. Despite being publicly developed under the CentOS Stream name, this tree is effectively RHEL. Additional upstream sources may be incorporated at fork time (e.g., RT bits for RHEL 10).

After the fork, ARK no longer feeds into the centos-stream tree. All contributions must arrive via merge requests that are peer-reviewed by Red Hat associates.

Streams

A stream is a version of the product, using the same terminology as product delivery. In RHEL versioning (X.Y), X is the major version and Y is the minor version. The stream concept is RHEL-specific; Fedora has its own independent release cycle, and ELN does not follow this model.

y-stream

The y-stream is the latest minor version currently in active development, prior to GA. The centos-stream repository always tracks the current y-stream. A typical RHEL minor release cycle is 6 months.

At the start of the exception/blocker phase:

The centos-stream branch is forked into a dedicated RHEL X.Y branch.
The minor version is bumped in the centos-stream tree, and development there continues toward the next RHEL minor release.

The forked RHEL X.Y branch goes through the exception/blocker phase and becomes the z-stream at GA. During this phase, any code landing in the RHEL X.Y branch must also land in the new y-stream (X.Y+1), to avoid introducing regressions there.

z-stream

The z-stream is a stable RHEL minor release under maintenance. It corresponds to the RHEL X.Y branch forked from centos-stream at the start of the exception/blocker phase, becoming official at GA. Changes are primarily fixes, though exceptions exist. Each minor release has its own EOL.

Some z-stream releases are designated for extended support under product offerings such as EUS (Extended Update Support), AUS (Advanced Update Support), and E4S (Extended Support for SAP Solutions). These are product-level support programs that provide longer maintenance windows for specific minor releases; the underlying kernel development model remains the same z-stream model.

centos-stream (RHEL X.Y — y-stream, active development)
    │
    │  [start of exception/blocker phase]
    │
    ├──▶ RHEL X.Y branch  (exception/blocker → z-stream at GA, until X.Y EOL)
    │
    └──▶ centos-stream (RHEL X.Y+1 — next y-stream)
              │
             ...

Lineage and Flow

Fedora and ELN are built directly from ARK — they do not consume it as a separate step; ARK is their source tree.

For each new major RHEL release, ARK is forked into a dedicated centos-stream tree. This fork may include additional upstream contributions beyond ARK (e.g., RT bits were added for RHEL 10). Development on this fork happens publicly in the centos-stream tree, but the code is effectively RHEL.

Linus' tree (mainline)
    │
    ▼
ARK tree (kernel-ark)                          gitlab.com/cki-project/kernel-ark
    │   Adds: Red Hat packaging, Fedora configs, future RHEL configs
    │
    ├──▶ Fedora  (built directly from ARK)
    ├──▶ ELN     (built directly from ARK)
    │
    └──▶ [fork per major RHEL release — clean cut, no ongoing ARK feed]
              │
              ▼
         centos-stream/kernel                   gitlab.com/redhat/centos-stream/src/kernel/<version>
              │   (one repo per major release; public, but effectively RHEL)
              │   All changes via peer-reviewed merge requests
              │   After exception/blocker phase and beyond GA: development moves private
              ▼
            RHEL                                gitlab.com/redhat/rhel/src/kernel/
                                                mirrored at gitlab.cee.redhat.com/kmaint/mirrors

Kernel Types

The table below compares the four production/build kernel types. Flavor, covered in the first subsection, is a different dimension — a distribution profile rather than a production model — and is not included in this comparison.

	Variant	Rebuild	Tied Derivative	Async Derivative
Source	Same	Same	Base + extra	Base + extra
Build process	Standard	Different buildroot	Separate	Separate
Produces variants	Yes	Yes	Yes	Yes
Schedule	Base kernel	Base kernel	Base kernel	Own
Testing	Variant-specific	Same as base	Additional on top	Likely dedicated

Variant

Rebuild

Tied Derivative

Async Derivative

Source

Same

Base + extra

Build process

Standard

Different buildroot

Separate

Produces variants

Yes

Schedule

Base kernel

Own

Testing

Variant-specific

Same as base

Additional on top

Likely dedicated

Flavor

A flavor represents a specific distribution profile. ARK carries two flavors:

Fedora — used to build the Fedora kernel
RHEL — used to build ELN and serves as the base for future RHEL releases

At fork time, when a new centos-stream tree is created for a major RHEL release, Fedora-specific files and configs are typically discarded.

Variant

A variant is a set of kernel binaries built from the same source tree but with a different kernel configuration. All variants are produced as part of the same build process. Almost all RHEL streams actively build and deliver several variants. The set of variants built by default differs between Fedora and RHEL flavors.

Variants include both architectural and configuration differences. Most variants come with two configurations: base and debug. Examples of variants:

stock — the default variant (formerly known as "up")
realtime — enables the realtime kernel
arm64_16k (aarch64 only) — enables 16k page size
arm64_64k (aarch64 only) — enables 64k page size
automotive — enables automotive platform support

Each variant has a dedicated rpmbuild switch to enable or disable it independently. This is useful for parallel variant builds, for example in CKI (Continuous Kernel Integration) pipelines. CKI is a CI-as-a-service initiative providing automated testing for Linux kernel changes.

Some spec file options act as variant modifiers and affect more than one variant. For example, enabling debug or gcov applies to all variants enabled during the build.

The table below shows which RPMs are produced depending on which variant switch (rows) and modifier switch (columns) are enabled. Each cell represents the RPMs built when both the row and column switches are active. Note that stock and realtime are just two examples — there can be more variants:

                  │  with_base        │  with_debug             │  with_gcov             │
──────────────────┼───────────────────┼─────────────────────────┼────────────────────────┤
  with_stock      │  kernel RPMs      │  kernel-debug RPMs      │  kernel-gcov RPMs      │
──────────────────┼───────────────────┼─────────────────────────┼────────────────────────┤
  with_realtime   │  kernel-rt RPMs   │  kernel-rt-debug RPMs   │  kernel-rt-gcov RPMs   │

Derivative

A derivative is a kernel built outside of the standard kernel build process, using kernel source code as a base with either additional source code applied or configurations enabled that are not supported in the base product(s) from which the source is derived.

For example, kernel-rt (realtime) was a RHEL derivative prior to RHEL 9.3. In 9.3, the kernel-rt patchset was integrated into the standard RHEL kernel build, making realtime a variant rather than a derivative.

Keeping a derivative fully up to date with base kernel development is an ongoing engineering effort; the work required scales with the size and complexity of the additional code and the frequency of base kernel updates.

Derivatives are generally tested like variants, with QE performing additional derivative-specific testing on top.

Derivatives range from tied — following the RHEL process and schedule closely — to async — operating on their own independent schedule.

Tied

A tied derivative follows the RHEL process and schedule, delivering at the same cadence as the kernel it is derived from. This simultaneous delivery schedule reduces operational complexity and allows for relatively easy automation of the build process. For example, RHiVOS (RHEL In-Vehicle Operating System) is a tied derivative.

Async

An async derivative operates on its own independent schedule, outside of the RHEL process. This adds complexity and overhead compared to a tied derivative. For example, Red Hat Enterprise Linux (RHEL) for NVIDIA is an async derivative.

Rebuild

A rebuild uses the same source tree with no additional modifications, but is built with a different buildroot and/or build options. A different buildroot typically means a separate dist-tag and build target, resulting in artifacts that are kept separate from RHEL and distributed independently. Because the source is identical to the base kernel, a rebuild produces the same set of variants. For example, kernel-automotive is a rebuild of RHEL 10.

Signing

Different kernel artifacts are signed in distinct ways:

Kernel modules — modules built alongside the kernel are signed with a key generated during the build process. This key is discarded at the end of the build. Out-of-tree kernel modules are signed by keys that the kernel explicitly trusts.
Kernel binary — signed for Secure Boot using the %pesign macro or rpm-sign (rh-signing-client).
UKI — signed the same way as the kernel binary, using the %pesign macro.
RPMs — signed separately from the kernel-specific signing infrastructure. This happens post-build and the kernel spec file has no knowledge of it.

Kernel Type Cost Comparison

Cost to introduce and maintain
─────────────────────────────────────────────────────────────────────────────────────────▶
Low                                                                                  High

 Rebuild                   Variant             Tied Derivative          Async Derivative
    │                         │                       │                        │
 Same source, different    Same build process,    Follows base kernel     Own schedule and
 buildroot and/or          different config       process and cadence,    cadence, additional
 build options                                    extra code/config,      integration complexity,
                                                  ongoing maintenance     ongoing maintenance
                                                  to keep in sync with    to keep in sync with
                                                  base kernel,            base kernel,
                                                  additional testing      likely dedicated QE
                                                                          for unique features