Kernel-driver co-evolution · automated

Your kernel upgraded. Your drivers didn't.

Multi-agent system that detects API drift, generates migration patches, validates end-to-end — compile, sparse, QEMU boot. No human in the loop.

View on GitHub Read the paper →
0%
Compile success rate
vs ~0% unassisted baseline
0
Validated migration cases
compile + sparse + QEMU boot
v5.10 → v6.10
Kernel version range
6 major releases covered
0
Validation stages
compile → sparse → QEMU → runtime
$kdrift migrate drivers/net/e1000e/ --from v5.10 --to v6.10
 
[scan] Detecting API drift across 6 releases...
[scan] Found 14 breaking changes in 8 subsystems
[classify] 9-class taxonomy applied, 3 semantic shifts
[migrate] LPA generating patches... 11/14 resolved
[migrate] GMA escalation for 3 remaining cases...
 
[validate] ✓ compile — 0 errors, 0 warnings
[validate] ✓ sparse — clean
[validate] ✓ QEMU boot — module loads, dmesg clean
 
✓ 14/14 migrations complete. Patch ready.
$
Built for teams tracking kernel-driver compatibility
0
Driver files
In the Linux kernel tree
0%
Kernel code
Is device drivers
~2.3
API breakages
Per driver per release
0
API migration cases
In DRIFTBENCH
0
Regression cases
In DRIFTBENCH
0
LLMs benchmarked
Frontier models evaluated
§ 01 — Problem

The kernel doesn't provide a stable driver interface

Every kernel release reshapes internal APIs. Drivers that compiled yesterday break tomorrow. Maintainers patch by hand — if they notice at all.

The Linux kernel explicitly maintains no stable in-kernel API. Greg Kroah-Hartman's canonical document stable_api_nonsense.txt makes this clear: internal interfaces change whenever there is a good reason. The result is that out-of-tree drivers — and even many in-tree drivers — break silently across releases.

For vendors shipping BSP kernels, custom hardware support, or long-lived embedded products, this means every upstream rebase is a manual audit of hundreds or thousands of call sites. Breakages range from trivial renames to deep semantic changes in locking, lifetime management, and error handling.

The cost compounds: teams defer upgrades, accumulate technical debt, and eventually ship kernels years behind upstream — missing security fixes, performance improvements, and hardware enablement.

Type A
API & ABI drift
Function signatures change, parameters are added or removed, return types shift. Headers reorganize, structs gain or lose fields. The compiler catches most of these — but not all.
Syntactic
Type B
Semantic realignment
Calling conventions, locking requirements, or error-handling contracts change without altering the signature. Code compiles but behaves differently. The hardest class to detect.
Semantic
Type C
Security hardening
APIs are deprecated for security reasons — raw accessors replaced with checked variants, direct memory operations wrapped in guards. Failure to migrate is a CVE waiting to happen.
Security
§ 02 — System

A closed-loop system, not a code generator

KDRIFT combines static analysis, LLM-based patching, and staged hardware validation into a single automated pipeline. Agents iterate until the patch compiles, passes sparse, and boots in QEMU.

Step 01
Detect
AST-differential analysis between kernel versions. Compares function signatures, struct layouts, macro expansions, and header includes across the target range.
AST-differential
Step 02
Classify
Each detected change is classified into one of 9 migration categories: rename, parameter change, return type, semantic shift, deprecation, split, merge, removal, or security hardening.
9-class taxonomy
Step 03
Migrate
Two-tier agent architecture. The Local Patch Agent (LPA) handles straightforward migrations. Complex cases escalate to the Global Migration Agent (GMA) with full repository context.
LPA + GMA two-tier
Step 04
Validate
Staged validation pipeline: kernel module compile, sparse static analysis, QEMU boot test with module loading, and runtime smoke tests. Failures trigger agent re-iteration.
Staged validation
Agent loop — iterative patch refinement
Stage 01 Agent
LPA Local Patch Agent
Fast-path single-file patching. Template-conditioned on the 9-class taxonomy. Handles routine API substitutions without tool access.
  • ~75% of cases resolved here
  • <1s latency per patch
  • Classes 1–4: signature, return, deprecation, struct
  • No tool access — works from AST delta alone
  • On failure → retry up to 3x with compiler errors
Stage 02 Gate
Staged validation
Four-stage pipeline. Each stage gates the next. Failures feed error context back to the originating agent for iterative refinement.
  • compile — GCC/Clang cross-build
  • sparse + smatch — static analysis
  • QEMU boot — module load + dmesg
  • lockdep + KASAN — runtime analysis
  • Failure at any stage → agent feedback loop
Stage 03 Agent
GMA Global Migration Agent
Escalation path for complex cases. Full repository context, cross-file rewrites, iterative refinement with compiler and runtime feedback.
  • ~25% of cases need GMA
  • 5 max iterations per feedback type
  • Classes 5–9: lifecycle, concurrency, security
  • Full tool access: grep, AST query, docs lookup
  • Converges or returns with diagnostics
56%
Pass all 4 stages
100% → 89% → 78% → 56%
Compile → sparse → QEMU → full
$0.07 – $3.29
Cost per migration run
168s – 1185s
Execution time range
Example migration — ida_simple_get → ida_alloc deprecation
drivers/net/ethernet/intel/e1000e/netdev.c v5.10 → v6.1 · API deprecation · auto-generated
@@ -1247,8 +1247,8 @@ static int e1000_probe(struct pci_dev *pdev,
    struct net_device *netdev;
    struct e1000_adapter *adapter;
-  int id = ida_simple_get(&e1000_ida, 0, 0, GFP_KERNEL);
+  int id = ida_alloc(&e1000_ida, GFP_KERNEL);
    if (id < 0)
      return id;
  
@@ -1389,3 +1389,3 @@ static void e1000_remove(struct pci_dev *pdev)
-  ida_simple_remove(&e1000_ida, adapter->id);
+  ida_free(&e1000_ida, adapter->id);
    free_netdev(netdev);
  }
+2 additions -2 deletions Classification: deprecation · Confidence: 0.97 · Agent: LPA
§ 03 — Results

Model comparison on DRIFTBENCH

Five frontier LLMs evaluated on 71 kernel-driver migration cases. Build success, AST similarity, and QEMU boot pass rate.

DRIFTBENCH v1.0 — 71 migration cases Staged validation · 4 retries · temperature 0
Model Build success AST similarity Sparse clean QEMU boot
Qwen3 Coder Plus 68.8% 84.2 62.5% 56.3%
Claude 3.7 Sonnet Best AST 70.8% 86.9 64.6% 58.3%
GPT-5 Codex 51.1% 78.4 45.8% 39.6%
Gemini 2.5 Pro 20.8% 61.3 16.7% 12.5%
DeepSeek R1 13.6% 52.7 10.4% 8.3%
All models evaluated with identical system prompts, 4-retry loop, and temperature 0. AST similarity measured via GumTree edit distance on the generated patch vs. ground-truth commit. QEMU boot tests run on defconfig x86_64 with the target module loaded.
§ 04 — Ecosystem

Three components, one mission

An open tool, a public benchmark, and a family of fine-tuned models — designed to work together or independently.

Tool
KDRIFT
CLI tool and CI integration for automated kernel-driver migration. Detect drift, generate patches, validate end-to-end. Plugs into existing build systems and CI/CD pipelines.
> Python + Rust core
> GitHub Actions / GitLab CI
> Configurable retry budget
> JSON / SARIF output
View repository →
Benchmark
DRIFTBENCH
Curated benchmark of 71 real kernel-driver migration cases spanning v5.10 to v6.10. 48 API migration cases plus 23 regression cases with ground-truth patches from upstream commits.
> 71 validated cases
> Ground-truth from upstream
> Reproducible eval harness
> Leaderboard + submission API
Explore dataset →
Models
KERN 7B / 32B
Fine-tuned model family specialized for kernel code understanding and driver migration. Trained on 50K+ kernel commits with migration-specific instruction tuning and DPO alignment.
> Based on Qwen3 Coder
> 7B and 32B variants
> Migration-specific LoRA
> Apache 2.0 license
Coming Q3 2026
Features

What ships today

Core capabilities available in the current beta release. Each feature is designed to work standalone or as part of the full pipeline.

01
AST-Differential Analysis
Semantic deltas, not line diffs. Compares abstract syntax trees across kernel versions to identify meaningful API changes independent of formatting, comments, or unrelated modifications.
Detection
02
9-Class Taxonomy
Each detected change is categorized into one of nine migration classes that condition the patch synthesis strategy — from trivial renames to complex semantic realignments.
Classification
03
Two-Tier Agents
LPA handles fast-path single-file patches. Complex multi-file cases escalate to GMA with full repository context, cross-reference resolution, and subsystem awareness.
Migration
04
Staged Validation
Four-stage pipeline: compile, sparse static analysis, QEMU boot with module loading, and runtime smoke tests. Each stage gates the next, with failure feedback driving re-iteration.
Validation
05
CI/CD Integration
Native GitHub Actions and GitLab CI support. Trigger migration checks on upstream kernel releases, PRs, or scheduled scans. SARIF output for code review integration.
Integration
06
linux-next Monitoring
Proactive drift detection against linux-next. Get notified of breaking changes before they land in a stable release — fix forward instead of catching up.
Monitoring
See all features →
§ 05 — Access

Open core, enterprise ready

The research and tooling are open. Enterprise features layer on top for teams that need CI/CD integration, vendor fork support, and SLA guarantees.

Open source
Free forever
  • KDRIFT CLI tool — detect, classify, migrate, validate
  • DRIFTBENCH dataset — 71 cases with ground truth
  • Evaluation harness — reproduce all paper results
  • Community support via GitHub Discussions
  • Apache 2.0 license
Get started
Enterprise
For teams at scale
  • CI/CD pipeline integration — GitHub Actions, GitLab CI, Jenkins
  • Vendor fork support — custom kernel trees, BSP branches
  • linux-next monitoring — proactive drift alerts
  • Priority support with SLA guarantees
  • Custom model fine-tuning on your driver codebase
  • On-premise deployment option
Talk to us →
Blog

Latest from the team

Technical deep-dives, benchmark analysis, and the business case for automated kernel-driver migration.

Architecture Mar 2026
Why Compiler Errors Are Not Enough
A clean build is necessary but not sufficient. We break down why KDRIFT uses four validation stages — and how each catches a different class of regression that the previous stage misses.
Read →
Business Mar 2026
The Cost of Delayed Kernel Upgrades
Teams that defer kernel rebases accumulate security debt, miss performance gains, and eventually face a multi-month catch-up. We quantify the cost and show how continuous migration changes the equation.
Read →
Newsletter  
Stay in the loop
Monthly updates on KDRIFT releases, DRIFTBENCH additions, and kernel migration research. No spam.
§ 07 — Contact

Get in touch

Whether you're evaluating KDRIFT for your team or have questions about the research — we'd like to hear from you.

Let's talk kernel migration
We typically respond within 24 hours. For enterprise inquiries, we can schedule a technical deep-dive with our engineering team.
> Email: hello@kdrift.dev
> GitHub: github.com/kdrift-dev
> Response time: < 24h
> Enterprise demo available