Kernel Testing logo

Kernel Testing

Community
mohitmishra786
kernel-testing

Linux kernel testing skill for KUnit, kselftest, syzkaller, and LTP. Use when writing KUnit tests, running kselftest harness, configuring syzkaller fuzzing, or integrating KernelCI. Activates on queries about kunit_test_suite, kunit.py, kselftest, syzkaller, kcov, or Linux Test Project.

Overview

Publishermohitmishra786
Repositorylow-level-dev-skills
Skill namekernel-testing
Stars
266
Forks
31
Bundled files
Instructions only
LicenseMIT
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • Self-contained

    Everything the model needs lives in the instructions — no extra files to sync.

  • Open source

    Published by mohitmishra786 on GitHub. Read the source before you install it.

Installation

Install the Kernel Testing AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/mohitmishra786/low-level-dev-skills/tree/main/skills/kernel/kernel-testing
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/mohitmishra786/low-level-dev-skills.git /tmp/low-level-dev-skills
mkdir -p .claude/skills
cp -r /tmp/low-level-dev-skills/skills/kernel/kernel-testing .claude/skills/kernel-testing
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Kernel Testing in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Kernel Testing on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Kernel Testing is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

Kernel Testing

Purpose

Guide agents through testing the Linux kernel: KUnit in-kernel unit tests, the kselftest harness, syzkaller fuzzing with kcov coverage, Linux Test Project (LTP) syscall regression, and KernelCI integration for continuous testing.

When to Use

  • Writing unit tests for kernel library code or driver helpers
  • Adding regression tests to tools/testing/selftests/
  • Fuzzing syscalls and ioctl interfaces with syzkaller
  • Measuring kernel code coverage with kcov
  • Running LTP for syscall compatibility validation
  • Setting up CI for kernel patches

Workflow

1. KUnit — in-kernel unit tests

c
// test_example.c
#include <kunit/test.h>

static void example_test(struct kunit *test)
{
    KUNIT_EXPECT_EQ(test, 1 + 1, 2);
    KUNIT_ASSERT_NOT_ERR_OR_NULL(test, kmalloc(16, GFP_KERNEL));
}

static struct kunit_case example_test_cases[] = {
    KUNIT_CASE(example_test),
    {}
};

static struct kunit_suite example_suite = {
    .name = "example",
    .test_cases = example_test_cases,
};
kunit_test_suite(example_suite);

MODULE_LICENSE("GPL");
makefile
# Makefile
obj-$(CONFIG_KUNIT) += test_example.o
bash
# Run KUnit (in-tree)
./tools/testing/kunit/kunit.py run

# Run specific test
./tools/testing/kunit/kunit.py run --filter example

# With cross-compilation
./tools/testing/kunit/kunit.py run --cross_compile aarch64-linux-gnu- \
    --arch arm64

KUnit runs in kernel context (UMH or dedicated kunit kernel). Use kunit_kmalloc for test allocations.

2. kselftest harness

bash
# Build all selftests
cd tools/testing/selftests
make -j$(nproc)

# Run all
make run_tests

# Run specific test
./memfd/memfd_test
./mount/run_unprivileged_remount.sh

Adding a new selftest:

tools/testing/selftests/mytest/
├── Makefile
├── mytest.c
└── config        # optional kconfig requirements
makefile
# tools/testing/selftests/mytest/Makefile
CFLAGS += -Wall
TEST_GEN_FILES := mytest
TEST_PROGS := mytest

include ../lib.mk
bash
# Run from top-level
make -C tools/testing/selftests/mytest run_tests

3. syzkaller fuzzing

bash
# Install syzkaller
git clone https://github.com/google/syzkaller
cd syzkaller && make

# Manager config (manager.cfg)
{
    "target": "linux/amd64",
    "http": "127.0.0.1:56741",
    "workdir": "/tmp/syzkaller",
    "kernel_obj": "/path/to/kernel/build",
    "syzkaller": "/path/to/syzkaller",
    "procs": 8,
    "type": "qemu",
    "vm": {
        "count": 4,
        "kernel": "/path/to/bzImage",
        "cpu": 2,
        "mem": 2048
    }
}
bash
# Start manager
./bin/syz-manager -config manager.cfg

# Reproduce a crash
./bin/syz-repro -config manager.cfg crash-report.txt

Kernel requirements: CONFIG_KCOV, CONFIG_DEBUG_FS, CONFIG_KASAN (recommended).

4. kcov — kernel coverage

bash
# Enable kcov on instrumented kernel
# CONFIG_KCOV=y in kernel config

# syzkaller uses kcov automatically
# Manual coverage via debugfs
ls /sys/kernel/debug/kcov/

Coverage guides syzkaller toward unexplored kernel paths.

5. Linux Test Project (LTP)

bash
# Build LTP
git clone https://github.com/linux-test-project/ltp
cd ltp
make autotools
./configure
make -j$(nproc)
make install

# Run syscall tests
cd /opt/ltp
./runltp -f syscalls

# Run specific test
./runltp -f syscalls -s pipe01

LTP categories: syscalls, FS, network, IPC, controllers, security.

6. KernelCI

bash
# Local kernel build test (simplified workflow)
# KernelCI tests patches against multiple defconfigs

# Submit build to KernelCI (project-specific tokens)
# See https://kernelci.org/docs/

# Check boot and kselftest results in KernelCI dashboard

Typical CI pipeline:

Patch → build (allmodconfig) → boot test (QEMU) → kselftest → LTP subset

7. Testing decision tree

What to test?
├── Pure kernel function logic → KUnit
├── Userspace-visible behavior (syscall, ioctl) → kselftest
├── Security/crash finding → syzkaller + KASAN
├── Regression across distros → LTP
└── Upstream patch CI → KernelCI

8. Debug-friendly test kernel config

CONFIG_KUNIT=y
CONFIG_KCOV=y
CONFIG_KASAN=y
CONFIG_DEBUG_INFO_DWARF5=y
CONFIG_FRAME_POINTER=y
CONFIG_FTRACE=y
bash
make kvm_guest.config   # reasonable test config base
scripts/config --enable KUNIT KCOV KASAN
make olddefconfig

Common Problems

SymptomCauseFix
KUnit tests not foundCONFIG_KUNIT disabledEnable in .config; rebuild
kselftest SKIPMissing kernel featureCheck config file requirements
syzkaller no crashesWrong VM configVerify QEMU boots; check kernel cmdline
kcov zero coverageCONFIG_KCOV offRebuild kernel with kcov
LTP massive failuresWrong environmentRun as root; check prerequisites in README
kunit.py hangsUML vs hardware mismatchSpecify --arch and cross-compile

Related Skills

  • skills/low-level-programming/linux-kernel-modules — modules under test
  • skills/kernel/device-drivers — driver logic to unit test
  • skills/kernel/kernel-debugging — debug failures found by tests
  • skills/runtimes/fuzzing — userspace fuzzing concepts (libFuzzer)
  • skills/runtimes/sanitizers — KASAN/KMSAN for kernel
  • skills/virtualization/qemu-kvm — QEMU for kernel boot testing

Frequently asked questions

What does the Kernel Testing AI skill do?

Linux kernel testing skill for KUnit, kselftest, syzkaller, and LTP. Use when writing KUnit tests, running kselftest harness, configuring syzkaller fuzzing, or integrating KernelCI. Activates on queries about kunit_test_suite, kunit.py, kselftest, syzkaller, kcov, or Linux Test Project.

Why use Kernel Testing on TypingMind?

Because you install it once and use it with any model. Kernel Testing is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Kernel Testing in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/mohitmishra786/low-level-dev-skills/tree/main/skills/kernel/kernel-testing. TypingMind reads its SKILL.md and installs it as a skill you can enable per chat.

Which AI models can use Kernel Testing?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Kernel Testing?

As many as you like. As long as a model supports skills, you can use Kernel Testing with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Kernel Testing AI skill free?

Yes. It is published on GitHub by mohitmishra786 under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇