Features

Every stage of kernel migration, automated

From API drift detection to QEMU boot validation. A closed-loop system that handles routine changes in sub-second latency and escalates complex rewrites to a global agent.

01 — Detection
AST-Differential Analysis
kdrift reconstructs abstract syntax trees across commit ranges to compute semantic deltas. Instead of diffing lines, it understands what actually changed in the API surface.
Function
Granularity
Signature, body, and call-site tracking per function
Struct
Field tracking
Field additions, removals, type changes, reordering
Cross-file
Dependency mapping
Tracks impact across headers, subsystems, and modules
$kdrift check drivers/net/e1000e/ --from v5.10 --to v6.10
 
  ● Scanning 847 commits across 23 files...
 
  Detected changes:
    12 signature changes
     4 deprecations (symbol → successor mapped)
     7 behavioral changes (lock ordering, error paths)
     3 struct reshapes (field additions in netdev_priv)
 
  ✓ 26 changes classified — 19 LPA, 7 GMA

Line-level diffs are insufficient for kernel migration. They miss semantic context — they cannot distinguish a parameter reordering from a behavioral change, or detect that a removed function has a designated successor. AST differencing captures the structural meaning of every change.

02 — Classification
9-Class Change Taxonomy
Every detected change is classified into one of nine categories, each with a defined migration strategy and agent assignment. This taxonomy determines whether a change is handled locally or escalated.
Class 01
Signature Change
Parameter additions, removals, or reordering. The most common change type — typically mechanical and fully automatable.
LPA
Class 02
Return Type Change
Modified return semantics, including type changes and new error-code conventions that propagate through call chains.
LPA
Class 03
Deprecation
Symbol replaced by a designated successor API. kdrift maps old-to-new and generates the replacement call with adapted arguments.
LPA
Class 04
Struct Reshape
Field additions, removals, and type changes in kernel data structures. Requires updating all access sites and initializers.
LPA
Class 05
Lifecycle Reorder
Init and teardown sequence changes. Probe/remove ordering shifts that can cause resource leaks or null dereferences if missed.
GMA
Class 06
Concurrency Model
Lock ordering changes, spinlock-to-mutex conversions, new atomicity requirements. Incorrect migration causes deadlocks.
GMA
Class 07
Error Handling
New error paths, stricter validation, changed errno conventions. Requires tracing all callers to propagate correctly.
GMA
Class 08
Security Hardening
Refcounting discipline, bounds checks, access control enforcement. Failing to adopt these creates exploitable vulnerabilities.
GMA
Class 09
Cross-Subsystem
Changes spanning multiple kernel subsystems — e.g., a networking API change that also affects power management hooks.
GMA
03 — Migration
Two-Tier Agent Architecture
Routine changes are resolved instantly by the Local Patch Agent. Complex rewrites are escalated to the Global Migration Agent with full tool access and iterative refinement.
LPA
Local Patch Agent
Fast, template-conditioned patches
Handles classes 1-4 (signature changes, return types, deprecations, struct reshapes). Sub-second latency, no external tool access needed. Template-conditioned generation produces deterministic, correct patches for mechanical changes. Resolves approximately 75% of all detected changes.
GMA
Global Migration Agent
Iterative, cross-file rewrites
Handles classes 5-9 (lifecycle, concurrency, error handling, security, cross-subsystem). Full tool access including compiler, sparse, and QEMU. Iterative refinement with up to 5 attempts, each informed by the previous failure. Handles the hardest 25% of changes.
Stage 01Agent
LPA Local Patch Agent
Template-conditioned single-file patching. No tool access needed. Resolves ~75% of cases at sub-second latency.
  • <1s latency
  • Classes 1–4: signature, return, deprecation, struct
  • On failure → retry 3x with compiler feedback
Stage 02Gate
Staged validation
Four-stage pipeline gating every patch. Failures feed back to the originating agent.
  • compile — GCC/Clang
  • sparse + smatch — static analysis
  • QEMU boot — module load
  • lockdep + KASAN — runtime
Stage 03Agent
GMA Global Migration Agent
Escalation for cross-file semantic rewrites. Full tool access, iterative refinement.
  • 5 max iterations
  • Classes 5–9: lifecycle, concurrency, security
  • Converges or returns diagnostics
75%
LPA resolution rate
<1s
LPA latency
5
Max GMA iterations
3.2x
Faster than manual
0%
LPA resolution
Patches resolved without escalation
0s
LPA latency
Sub-second template generation
0
Max GMA iterations
Each informed by prior failure
0x
Faster than manual
End-to-end migration time
04 — Validation
Staged Pipeline
Every generated patch passes through four validation stages. Each stage catches a distinct class of defect that the previous stage cannot detect.
Stage 1
Compile
GCC/Clang cross-compilation
Syntax & Symbols
Stage 2
Sparse + Smatch
Static analysis pass
Lock & Type Safety
Stage 3
QEMU Boot
Full kernel boot with driver
Init & Probe
Stage 4
Runtime
lockdep + KASAN under load
Memory & Deadlocks
Stage 1 — Compile
GCC/Clang Cross-Compilation
Catches syntax errors, missing symbols, type mismatches, and undeclared identifiers. The first gate ensures the patch produces a valid object file. Every patch must compile cleanly on both GCC and Clang before proceeding.
Stage 2 — Sparse + Smatch
Static Analysis
Catches lock ordering violations, null pointer paths, type confusion, and address space mismatches that compile but are semantically wrong. Finds defects invisible to the compiler.
Stage 3 — QEMU Boot
Full Kernel Boot
Boots a complete kernel with the driver loaded in QEMU. Catches init failures, probe errors, resource conflicts, and incorrect registration sequences that only manifest at runtime during module loading.
Stage 4 — Runtime
lockdep + KASAN
Dynamic analysis under synthetic load with lockdep (deadlock detection) and KASAN (memory sanitizer) enabled. Catches memory corruption, use-after-free, double-free, and lock inversion that only appear under concurrent access.
0%
Compile
All patches compile cleanly
0%
Pass sparse
Static analysis clean
0%
QEMU boot
Successful kernel boot with driver
0%
All 4 stages
Full pipeline pass rate
05 — CI/CD
CI/CD Integration
Drop kdrift into your existing pipeline. Native support for GitHub Actions and GitLab CI, with a CLI fallback for any environment.
# .github/workflows/kdrift.yml
name: kdrift migration check
on:
  schedule:
    - cron: '0 6 * * 1'
  workflow_dispatch:
jobs:
  migrate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: kdrift/action@v1
        with:
          drivers: drivers/net/e1000e/
          target: v6.10
          validate: full
⚡
GitHub Actions
First-class action with scheduled and on-demand triggers. Auto-creates PRs with migration patches.
Native
⚙
GitLab CI
Template include for .gitlab-ci.yml. Supports merge request pipelines and scheduled scans.
Native
⛏
Jenkins
Pipeline library with Jenkinsfile integration. Tested with declarative and scripted pipelines.
Plugin
▸
Manual / CLI
Run kdrift directly from any shell. Full control over detection, migration, and validation stages.
Universal
06 — Monitoring
linux-next Tracking
Proactive drift detection against linux-next. kdrift scans upstream daily, detects API changes that affect your drivers before they land in a stable release.
$kdrift watch --drivers drivers/net/e1000e/ --upstream linux-next
 
  ● Watching linux-next for changes affecting e1000e...
 
  [2026-03-14 06:00] Scan complete
    ▲ ALERT netdev_priv() return type change in next-20260313
      commit: a3f7c2e — "net: make netdev_priv return void pointer"
      class: 02 (Return Type Change) → LPA candidate
      eta: ~3 weeks to stable
 
    ▲ ALERT pci_alloc_irq_vectors() new flags parameter
      commit: d91be4a — "PCI/MSI: add flags argument to alloc_irq_vectors"
      class: 01 (Signature Change) → LPA candidate
      eta: ~2 weeks to stable
 
  ✓ 2 upcoming changes detected — patches pre-staged
Daily
Scan frequency
Automated scans against linux-next HEAD
2-4 wk
Advance warning
Lead time before changes hit stable
Zero-day
Migration readiness
Patches ready before upstream lands
Get started
Ready to automate your kernel migrations?
Start with a single driver. kdrift handles the rest.