Align using kernel version 6.18 LTS as the supported syscall surface - #303
Merged
Conversation
uname(2) and /proc/version each spelled the reported kernel as a private string literal, in syscall/sys.c and runtime/procemu.c, free to drift apart. Both now read GUEST_KERNEL_RELEASE and GUEST_KERNEL_VERSION from syscall/sys.h, which procemu.c already includes. The reported values are unchanged. Verified: the new tests/test-proc.c case pins the uname release into the /proc/version banner, and fails when the two are forced apart.
The old release claimed a lima aarch64 VM kernel, but no lima configuration or provisioning exists in this repo, and the only kernel the tree boots is the qemu oracle's Alpine linux-virt. The release now names the 6.18 LTS baseline, maintained through December 2027, and tracks no image. Against dispatch.tbl, 6.18 is the smaller gap: 6.17 added file_getattr and file_setattr, both above SC_MAX_SYSCALL_NUM and ENOSYS here, while 6.18 added no syscalls. glibc's dl_discover_osversion rejects only a release below its build-time floor, so raising the number is the safe direction. The /proc/version banner loses the buildd@bos03-arm64-051 builder and the Ubuntu toolchain spellings: that host never built this, and no Ubuntu release ships a 6.18 kernel. The builder and compiler fields are now fixed elfuse strings in the proc_version_show format. Coverage: tests/test-comprehensive.c asserts release >= 6.18 where nodename is elfuse, so the same binary passes under the qemu oracle; the check was seen failing with the floor raised past the release.
No doc named the kernel elfuse claims, the surfaces carrying the claim, or its limits. docs/internals.md gains a Reported Kernel Identity section: the two surfaces and their one definition, the 6.18 LTS rationale, the frozen LINUX_2.6.39 vDSO tag, the calls a real 6.18 provides that elfuse answers with -ENOSYS, and the three things that read the release automatically. dispatch.tbl is the implemented set with two exceptions, so the section names them: pidfd_getfd and userfaultfd are registered there but their handlers return -ENOSYS. The readers are named per lane, since test-proc and test-comprehensive both run under elfuse and under the qemu oracle, and bench-hot-guard-glibc reads the release through glibc's uname fallback without asserting on it. README.md and docs/usage.md each carry one line, since a guest user observes the version directly.
The oracle ran Alpine 3.21's linux-virt 6.12 while elfuse reports 6.18, so the differential lanes compared against a kernel two LTS lines behind the claim. linux-virt now resolves from the Alpine 3.23 main repo, which ships 6.18; the kernel and its lib/modules tree come from that one apk, so the 9p and virtio-net modules the boot init loads match the kernel. The 37 userland pins stay on 3.21. Verified: qemu_exec uname -r prints 6.18.44-0-virt, the 9p mount holds, and both matrix lanes stay at their baselines.
Three comments assert a live correspondence with a lima VM that exists nowhere in the repo: the sysinfo RAM cap says "Match Lima VZ 4GiB VM", rosetta.h says the probe values "match what the Lima-on-VZ Linux VM observes", and proc.c restates its own provenance sentence as "matching a real VZ (Lima) VM". The values are captured data; the comments now say so and stop implying a sync obligation. tests/test-poll.c stops naming lima as a lane the matrix does not have; the setpgid variance is session-leader status, which follows the launcher.
henrybear327
force-pushed
the
kernel/6.18-lts
branch
from
August 16, 2026 21:44
da85c22 to
f54c034
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently, we are using kernel version 6.17 for the kernel syscall interface, and 6.12 for our qemu conformance test (alpine 3.21 is on Linux kernel version 6.12). This PR also cleans up the stale Lima-related comments.
There isn't any new syscall introduced between 6.17 and 6.18.
As 6.18 is a LTS kernel, it would be beneficial for us to support a kernel version that will last for years.
Summary by cubic
Aligns the reported and reference kernel with Linux 6.18 LTS. Guests now see 6.18 from uname and /proc/version, and the qemu oracle boots an Alpine 6.18 kernel; previously uname/proc reported 6.17 and the oracle ran 6.12. Syscall coverage is unchanged.
uname(2)and/proc/versionread these.tests/test-proc.cenforces banner/uname agreement;tests/test-comprehensive.casserts release >= 6.18 when nodename is elfuse.src/syscall/dispatch.tblremains the implemented set; unimplemented 6.18 syscalls still return -ENOSYS.tests/fetch-fixtures.shfetcheslinux-virtfrom Alpine 3.23 viaKERNEL_ALPINE_VERSION(default 3.23) so the kernel andlib/modulesmatch; userland pins stay on Alpine 3.21.docs/internals.mddocuments the identity surfaces and limits.Written for commit f54c034. Summary will update on new commits.