Appendix C-Contributing to the Linux Kernel: A Playbook¶

The Linux kernel is famously approachable, and famously demanding. This appendix is the on-ramp.

C.1 Mental Model¶

The Linux kernel is developed via mailing lists (LKML and per-subsystem lists), with patches sent inline via git send-email. There is no GitHub PR equivalent. Reviewers reply on-list; subsystem maintainers (MAINTAINERS file) merge into their trees; Linus pulls from those into mainline.

Implications: 1. You send patches as emails, not PRs. 2. The cultural norm is direct, sometimes blunt feedback. Do not take it personally. 3. The maintainer set is finite and busy. A two-week response cycle is normal; six weeks is not unusual; ignored = re-send a polite ping.

C.2 Setting Up¶

git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux
make defconfig    # or copy your distro's config
make -j$(nproc)

For development, prefer working off the subsystem tree (e.g., net-next for networking work, tip for sched/locking, staging for drivers in incubation). The MAINTAINERS file lists per-subsystem trees.

Configure git:

git config sendemail.smtpserver smtp.example.com
git config sendemail.smtpuser you@example.com
git config user.signingkey "..."

C.3 Where the Easy Wins Are¶

C.3.1 Documentation¶

Documentation/ is large and uneven. Typo fixes and clarifications are welcomed by linux-doc@vger.kernel.org.
Trivially good first patch.

C.3.2 Coding-style fixes¶

scripts/checkpatch.pl flags style violations. Submit a series fixing them. (But: huge mass-style patches are sometimes resisted as churn-limit to one file or one subsystem.)

C.3.3 Staging drivers¶

drivers/staging/ is the incubator for drivers being prepped for mainline. Cleanup work here (sparse fixes, checkpatch, removing unused code) is well-supported.

C.3.4 New tracepoints / debugfs entries¶

Adding a tracepoint to expose useful info to eBPF tooling is a tractable medium-difficulty contribution. Discuss design on-list first.

C.3.5 Bug fixes¶

The bugzilla.kernel.org tracker has reproducible bugs. Pick one in a subsystem you understand.

C.3.6 Don't start here (yet)¶

Scheduler core (kernel/sched/).
Memory management core (mm/).
Networking core (net/core/, net/ipv4/tcp*).
VFS core (fs/namei.c, fs/dcache.c).

C.4 The First-Patch Workflow¶

Pick a small change. A typo, a checkpatch warning, a tested driver fix.
Make the change in a branch.
Run scripts/checkpatch.pl --strict <patch>. Fix all warnings.
Build the affected subsystem. For drivers: make M=drivers/foo/.
Test on real or virtual hardware. A patch with no Tested-by is suspect.

Commit with a kernel-style message:

subsys: short imperative description (under 70 chars)

Body explaining the problem and why this change fixes it. Past tense
for the bug ("crashed when..."), imperative for the fix ("Avoid the
crash by checking..."). Wrap at 72 columns.

Fixes: <12-char-sha1> ("subject of bug-introducing commit")
Cc: stable@vger.kernel.org # if backport-worthy
Signed-off-by: Your Name <you@example.com>

The Signed-off-by is a DCO (Developer Certificate of Origin) declaration; mandatory.

Identify the recipients:
```
./scripts/get_maintainer.pl --no-rolestats <patch>
```
This lists the subsystem maintainer, reviewers, mailing list. Send to all; CC LKML.

Send:

git send-email --to=maintainer@... --cc=list@... <patch>

Address review. Reviewers may ask for: design changes, additional testing, breakup into multiple patches. Each new version is [PATCH v2] subsys: .... Always include a changelog after - --` describing what changed since v1.
Maintainer applies. Your name and email go into the commit log.

C.5 The MAINTAINERS Map¶

The MAINTAINERS file at the root of the tree lists, for every subsystem: maintainer(s), reviewers, mailing list, source files in scope, status (Maintained / Supported / Odd Fixes / Orphan).

get_maintainer.pl parses it. Always run before sending a patch.

C.6 Reading Map¶

For depth, in this order:

File	What it teaches
`Documentation/process/submitting-patches.rst`	Authoritative process. Read first.
`Documentation/process/coding-style.rst`	The kernel's C style; non-negotiable.
`Documentation/process/email-clients.rst`	Why your email client matters.
`Documentation/dev-tools/sparse.rst`	Kernel-specific static analysis.
`Documentation/admin-guide/cgroup-v2.rst`	The cgroup-v2 interface, normative.
`Documentation/scheduler/sched-design-CFS.rst`	CFS / EEVDF design.
`Documentation/vm/`	Memory management deep dives.
`Documentation/networking/`	Per-subsystem networking docs.
`Documentation/bpf/`	Modern eBPF design and ABIs.

C.7 Adjacent Targets if Mainline Is Too Heavy¶

bpftrace-high contribution velocity, friendly maintainers.
bcc-older but still active.
perf userspace tools-tools/perf/ in the kernel tree, but its own dynamic.
util-linux-mount, lsblk, nsenter, etc. Active, contributor-friendly.
systemd-large but well-organized; on GitHub, with PRs.
iproute2-ip, tc, ss. Smaller surface, important.

A merged contribution to any of these signals real Linux fluency.

C.8 Calibration¶

A reasonable goal for a curriculum graduate:

By end of week 23: a patch sent to LKML or a subsystem list (could be a doc fix or a checkpatch cleanup).
By end of capstone: that patch merged.
6 months post-curriculum: a substantive contribution-a driver fix, a small tracepoint addition, or a bpftrace tool merged.

Patient, persistent contributors become trusted contributors. Trusted contributors become maintainers.