Contributing to the
Linux kernel.

There is no "fork & open PR." The kernel runs on a model that predates and outlives GitHub, and the sooner it clicks, the sooner everything else makes sense.

• Patches are emails. You mail a diff, in plain text, to a mailing list and the right maintainers. Review happens by reply.
• Maintainers, not merges. Each subsystem has a maintainer who curates a tree. They apply your patch to their tree; it flows upward from there.
• Trust is earned in public. Your Signed-off-by is a legal-ish certification (the DCO). Your track record is the sum of your accepted patches.

The upside: it's radically decentralized, scriptable, and durable. The cost: a workflow you have to learn deliberately — which is the rest of this deck.

No step here has a button. Every arrow is a person, a script, or a convention. We'll walk each.

Cloning Linus's mainline is fine for reading, but you develop against the maintainer tree your patch will target — so you're building on what they'll actually apply to.

• Good first targets: bpf-next (BPF features) or net-next (networking) — small, well-bounded, friendly to newcomers.
• Add it as a remote alongside mainline; develop on a topic branch named for the change.
• Rebase onto the latest -next before sending, so it applies cleanly.

The MAINTAINERS file lists every subsystem's tree URL, lists, and maintainers — scripts/get_maintainer.pl reads it for you (slide 14).

A full defconfig builds thousands of modules you'll never load. Start from your running kernel and trim — builds go from "make a coffee" to "make a sip."

• make localmodconfig — keep only what's loaded right now. Massively smaller.
• ccache + make -j$(nproc) — cache and parallelize; incremental rebuilds become seconds.
• Turn on the debuggers you'll want: KASAN, KCSAN, lockdep, DEBUG_INFO_BTF (for BPF CO-RE).

First build is slow; every build after is incremental. Optimize the loop, not the first run.

A patch that does three things is three times as hard to review and impossible to revert cleanly. Split work into a series where each patch stands on its own and builds.

• Each patch compiles & passes tests on its own — bisection must never land on a broken commit.
• Refactor, then change. A "move code" patch and a "change behavior" patch are separate, so the reviewer sees the real diff, not noise.
• A cover letter ([PATCH 0/N]) explains the series as a whole; each patch explains itself.

"Why," not "what." The diff shows what changed; the commit message must explain the reasoning a reviewer can't infer.

Reviewers reward a clean series with fast review. A 600-line do-everything patch sits unread.

A class of feedback you can avoid entirely by running the tools first. Maintainers have zero patience for issues a script would have caught.

• checkpatch.pl --strict — coding style, common mistakes. Clean it before sending.
• get_maintainer.pl — the exact people and lists to address. Don't guess.
• Clean build with W=1, and sparse (make C=1) for the subtle type bugs.
• Run the relevant selftests — and add one for your change.

CI bots (kernel test robot, BPF CI) run more — but failing the basics in public is an avoidable bad first impression.

The mechanics that trip everyone up — threading, versioning, To/Cc from MAINTAINERS, trailers collected from replies — are exactly what b4 automates.

• b4 prep starts a tracked series off a base; b4 send builds and mails it, correctly threaded.
• b4 trailers -u pulls reviewers' Reviewed-by tags back into your commits for v2.
• Send a test patch to yourself first. Confirm it applies with git am.

Hard rules: plain text only, no HTML mail, no line-wrapping the diff. A mangled patch is dead on arrival.

get_maintainer.pl tells you the people; you still choose the tree and the timing. For networking this is sharp:

• [PATCH net] — a fix for the current release. Goes to the net tree, accepted throughout the cycle.
• [PATCH net-next] — a feature for the next release. Goes to net-next — closed during the merge window.
• Put the target in the subject prefix so the maintainer (and patchwork) routes it correctly.

BPF mirrors this: bpf (fixes) vs bpf-next (features), list bpf@vger.kernel.org, tracked in its own patchwork.

Always Cc the lists and people, never BCC. The public archive (lore) is the system of record.

Almost nothing lands at v1. Review is terse, sometimes blunt, occasionally silent. The skill that separates contributors from quitters is persistence with grace.

• Reply inline, point by point. Agree and fix, or explain why not — politely, with reasoning.
• Send a v2 as a new thread, with a changelog under the --- and a link to v1 on lore.
• Collect trailers: Reviewed-by, Acked-by, Tested-by carry forward into each version.
• Silence ≠ no. A polite ping after ~1–2 weeks is expected, not rude.

Most "first patch" advice points at drivers/staging cleanups. You can usually do better: start where your existing knowledge is leverage. If you've touched eBPF or the network stack, that corner is unusually welcoming:

• BPF selftests — tools/testing/selftests/bpf, tree bpf-next, list bpf@vger.kernel.org. Add/fix a test: valued, low-risk, and the intent is clear.
• Networking — tree net-next, list netdev@vger.kernel.org. TCP/connect/socket-state knowledge maps straight onto net/ipv4/….
• A syzbot bug in BPF/net — a real, reproducible bug is the highest-credibility first patch.

You don't need a contrived starter task — a real tool will hand you one. Take NetWatch as a worked example: its eBPF Phase 2 wants broader attribution, and every hook it adds means reading the exact kernel networking source a netdev contributor reads.

• tcp_v6_connect — IPv6 attribution, the natural sibling of the Phase-1 kprobe.
• the UDP send path — so QUIC (which NetWatch already decrypts) gets per-process attribution.
• inet_sock_set_state — catch short-lived flows the connect-entry probe misses.

Each is the same question this deck answered for patches, asked of the kernel: which hook sees the event, what's populated when it fires, what's the stable key.

The #38 timing bug from the eBPF deep-dive is exactly this kind of question. Answer enough of them and you’re a kernel contributor — without ever forcing it.