ajksunkang-aios/KGraph

English | 中文

<div align="center">

KGraph

Compiler-Aware Kernel Graph Engine · MCP Tool Service

Config-aware · Macro-resolved · Function-pointer-callable · SQLite-native

Design Document →

<br>

KGraph indexes what the compiler sees — not what the parser guesses.

</div>

---

Why KGraph?

Kernel code is not regular code. It lives behind #ifdef CONFIG_*, inside SYSCALL_DEFINE* macros, behind file_operations function-pointer tables that tree-sitter can't follow. Existing tools (codegraph, semcode) parse syntax — KGraph parses compilation truth.

| What others miss | What KGraph captures | |---|---| | All #ifdef branches (most are dead under your config) | Only the code your defconfig actually compiles | | EXPORT_SYMBOL / SYSCALL_DEFINE* as opaque text | Macro-expanded symbols with real names and positions | | f_op->read_iter() → "can't resolve" | ops_bind edge: .read_iter = ext4_file_read_iter → concrete function | | Same-named static helpers across TU → name collision | Per-TU disambiguation via clang symbol resolution |

Result: LLM agents find root-cause paths in 3 tool-calls / ~1.5k tokens where grep-based workflows burn 10k+ tokens and scatter across irrelevant branches.

---

Workflow at a Glance

Once your kernel has a compile_commands.json, the whole setup is three commands:

# 1. Install kgraph (bundles Python 3.10 + scip-clang, Linux x86-64 only)
npm install -g @ajksunkang-aios/kgraph

# 2. Wire kgraph's MCP server into your AI agents (auto-detects what's installed)
kgraph install

# 3. Build the code graph for this kernel (run inside the kernel source dir)
cd /path/to/linux
kgraph init .

That's it. Restart your agent and ask it structural questions about the kernel — it calls KGraph's MCP tools instead of grepping.

> What functions call ext4_file_read_iter?
> What implements ->read_iter across the kernel?
> Show me the