Repository navigation
Choose one or more representative Linux kernel #801
Description
Background
Currently, our master branch uses the Linux 6.1.x kernel for system-mode development and CI workflows. However, 6.1.x is beginning to age out of important features, such as the EEVDF scheduler introduced in 6.6.x (link).
The Problem
We should bump our baseline to 6.6.x or newer. However, kernel.org currently lists four active LTS series (6.1.x, 6.6.x, 6.12.x, 6.18.x) and the newest stable release (7.2.x). Since running all of these versions in our CI workflow is impractical, we need to decide which version is the most representative for ongoing development.
Proposed Strategy
I propose we select our baseline using the following criteria:
- Pick an LTS version with at least 2 years of EOL remaining from release, OR pick an LTS version that introduces major milestones (e.g., EEVDF replacing CFS).
- Run a secondary CI check against the latest stable release to ensure compatibility with the newest codebase.
@jserv @visitorckw Any thought for this?
Activity
visitorckw commentedon Oct 13, 2026
Thanks for bringing this up.
I am wondering about your point that running all of these versions in our CI is impractical.
Could you share the specific reasons or main constraints behind this?
ChinYikMing commentedon Oct 13, 2026
Hi @visitorckw , thanks for quick response.
IMO, I think we should do
validationinstead ofstabletests across multiple versions. So, the original purpose is selecting theleast representativeversion. Also from previous experience, github action resources might be limited and scarce, for example the macOS instances, a bursty parallel CI workload might increase the job pickup time.visitorckw commentedon Oct 13, 2026
So it sounds like the main reason we want to update the kernel version in rv32emu is to run new software features on the emulator?
Normally upstream Linux releases one LTS version per year.
What if we upgrade to the latest LTS kernel once a year?
Ideally, this shouldn't require too much effort.
ChinYikMing commentedon Oct 13, 2026
Sounds good for the LTS.
What about the latest stable version? Does it worth to use it before it becomes a LTS version?
visitorckw commentedon Oct 13, 2026
I'm not quite sure how we would define "worth" in this context.
On second thought, I feel this is more of a process issue.
If we only care about certain new software features from time to time, we could also consider updating on demand.
Ultimately, I think it comes down to what our goals are or what problems we want to address.
ChinYikMing commentedon Oct 18, 2026
Adding a secondary stable Linux track provides several advantages:
Capture the kernel APIs changes earlier and automatic: The system emulation mode has a out-of-tree filesystem simplefs artifact which VFS APIs might change over the time (see Update fsync helper for linux 7.1 simplefs#93). Once this happens, simplefs can be patched and fixed earlier.
Validation of toolchain and kernel: Ensure the compatibility of the Buildroot toolchains and kernel updates before they roll out to the LTS.
Bug detection: Isolates stable kernel or emulator regressions.