From your first patch to a major contribution
The roadmap teaches you the kernel. This is the other half: how you actually get your code into Linus's tree. It is a ladder, not a leap — every kernel maintainer alive started with one tiny, terrifying first patch. Here is the climb, stage by stage.
The one mindset that matters: this is a long game measured in months and years, and it runs on trust. You are not buying your way in with a clever patch — you are building a reputation, one careful, honest, well-tested change at a time. Consistency beats brilliance. Be the person maintainers are glad to see in their inbox.
Six stages from outsider to insider
- 0
Set up your forge
Weeks 1–2Be able to build, boot, and email a patch — before you write a single line.
- Build & boot in QEMU. Compile the kernel from source and boot it in QEMU. It's fast, safe, and you can't brick your laptop. This is your iteration loop — make it tight.
- Wire up git send-email. Set your real name and a working git send-email. Kernel patches travel as plain-text email — not GitHub PRs. HTML mail is silently dropped by the lists.
- Read the process docs. Documentation/process/ — especially submitting-patches.rst, coding-style.rst, and “A guide to the Kernel Development Process.” This is the rulebook; reading it puts you ahead of 90% of first-timers.
- Learn the scripts. scripts/checkpatch.pl (style/correctness linter), scripts/get_maintainer.pl (who to CC), and the b4 tool (fetch & manage patch series from the lists).
- Subscribe via lore. Pick one subsystem list plus LKML on lore.kernel.org and just read for a week. Absorb the rhythm, the tone, and what good patches look like.
- 1
Land your first patch
Month 1Get one small, genuinely-correct patch accepted. The first one is the hardest.
- Pick a real, tiny fix. A true bug or improvement — a checkpatch --strict warning that's actually wrong, a compiler warning under make W=1, a sparse warning, a deprecated-API replacement, or a documentation/comment error you verified.
- Where to look. drivers/staging/ has a gentler bar; the syzbot dashboard and bugzilla.kernel.org list real reproducible bugs; KernelNewbies has a “first patch” tutorial; the (archived) Eudyptula Challenge tasks are a superb structured ramp.
- One change per patch. Each patch does exactly one logical thing. The commit message explains WHY, not just what. End with your Signed-off-by line (the Developer's Certificate of Origin).
- Self-check before sending. Run checkpatch.pl on your patch, build it (ideally W=1 and sparse), and read your own diff as a reviewer would. Catch it before they do.
- Don't patch-farm. Maintainers despise floods of trivial whitespace/typo patches sent for credit. One useful change beats fifty cosmetic ones — and protects your reputation from the start.
- 2
Pick a home & go deep
Months 2–6Become genuinely fluent in ONE subsystem instead of shallow everywhere.
- Choose a subsystem you care about. A driver class for hardware you own, or a filesystem, networking, memory management (mm), or the scheduler. Caring about it is what carries you through the hard months.
- Read code AND history. git log -p teaches you why the code is the way it is. The mailing-list archives on lore show the arguments behind each design. Read both — the code is only half the story.
- Build a toy to learn the APIs. Write a small out-of-tree module: a character device, a platform driver. Internalize the data structures (task_struct, file_operations, sk_buff) by using them.
- Watch it actually run. ftrace, perf, and bpftrace turn the kernel from a black box into something you can observe. Add KUnit tests for the code you touch.
- Review other people's patches. The single fastest way to learn the bar — and to get noticed. A careful Reviewed-by / Tested-by on the list is valued and builds your name before you're a heavy committer.
- 3
Become a regular
Months 6–18Maintainers know your name and trust your work.
- Ship a steady stream. A consistent flow of real, non-trivial fixes and small features in your subsystem. Consistency over heroics — reputation compounds patch by patch.
- Handle review like a pro. Address every comment. Send v2/v3 with a changelog under the --- line. Never argue from ego; the goal is the best patch, not being right.
- Triage and bisect bugs. Pick up syzbot reports and regressions. git bisect to find the culprit commit. Fixing others' bugs builds enormous goodwill with maintainers.
- Help the next newcomer. Answer questions on the list, review first-timers' patches. Becoming part of the community — not just a patch-sender — is what unlocks the bigger work.
- 4
Land something notable
The milestoneA contribution people cite — the “major” one.
- What “major” looks like. A new driver for real hardware; a new feature, syscall, or ioctl; a measurable performance win backed by benchmarks; fixing a whole class of bugs; a new API or subsystem; a substantial Rust-for-Linux or eBPF addition.
- Send an RFC first. Float the design as an RFC to get directional buy-in BEFORE writing it all. It's far cheaper to change a paragraph than 4,000 lines after a maintainer says “no.”
- Justify with data. For anything performance-related, bring numbers: before/after benchmarks, real workloads, the tradeoffs. “Trust me” doesn't merge; measurements do.
- Split into a reviewable series. A 4,000-line wall is unmergeable. Break it into a logical patch series, each independently reviewable, building up to the feature.
- Persist through revisions. Major work takes v5, v9, months. Expect pushback, line up Reviewed-by/Acked-by from the right people, and keep going. Persistence is the actual skill.
- 5
Toward maintainer
The long gameStewardship — years, not months.
- Trust is earned, then formalized. Sustained quality plus reviewing earns it. Eventually you may co-maintain a driver or file — adding yourself to MAINTAINERS, carrying patches, and mentoring the people who are where you started.
- Consistency beats brilliance. Nobody becomes a maintainer in a sprint. The people who get there showed up, did careful work, and were good to work with — for years. That's the whole secret.
What actually happens to a patch
Every contribution — your first typo fix and your eventual new driver — travels the same path from your laptop to the mainline tree. Step through it:
Turn your commit into a plain-text patch with a Signed-off-by line.
Your patch's journey from your laptop to Linus's tree. Click a step.
The tips & tricks that get patches accepted
Most first patches are rejected for process, not code. Get these right and you instantly look like you belong.
- +Send plain-text email with git send-email
- +One logical change per patch
- +Explain WHY in the commit message
- +Run checkpatch.pl + build (W=1, sparse) first
- +CC get_maintainer.pl people and the list
- +Reply inline; trim quoted text
- +Version patches: v2/v3 with a changelog under ---
- +Add Signed-off-by (the DCO)
- +Research prior art on lore.kernel.org
- +Be patient and humble under review
- −Send HTML email (it's dropped silently)
- −Bundle unrelated changes together
- −Patch-farm trivial whitespace for credit
- −Resend a new version with no changelog
- −Argue from ego when reviewed
- −Ping aggressively — wait ~1–2 weeks
- −Break the build or skip testing
- −Send a giant unreviewable mega-patch
- −Top-post replies on the list
- −Forget the Signed-off-by line
Where to find your first real task
Live, reproducible kernel bugs found by fuzzing — many beginner-friendly.
Reported bugs across subsystems; filter by component you know.
The canonical first-patch walkthrough and a friendly community.
The on-ramp area — a lower bar for cleanup and learning.
The compiler and static analyzers hand you a to-do list of real warnings.
Searchable archive of every list — research how a change was discussed before.
What a notable contribution looks like
A “major” contribution isn't one heroic patch — it's something the community comes to rely on. In recent years that has looked like: whole new drivers for real hardware, the eBPF programmable-kernel machinery, io_uring async I/O, sched_ext (pluggable schedulers in BPF), and the Rust-for-Linux effort. None landed in one shot — each was an RFC, then a patch series, then v2…v15, then months of review. You get there by being the person who already shipped a hundred good small patches in that subsystem and earned the right to propose something big.