Subsystems

Foundations taught you to write kernel code. Contribution taught you to get it merged. Neither told you what to change, and that is the part that takes years.

This section is the bridge. You will read all eight domains at orientation depth, choose one, and go deep enough in it to have an opinion a maintainer would engage with.

Learning Objectives

The Method

You will use this eight times. It is the same method from the mental model, expanded, and it is the single most transferable thing in this curriculum: it works on any large codebase, not just this one.

 1. WHO OWNS IT?
      ./scripts/get_maintainer.pl --scm --status -f <dir>
      git log --since="1 year ago" --format='%cN' -- <dir> | sort | uniq -c | sort -rn | head
      Formal ownership from MAINTAINERS; actual activity from git log. They differ.

 2. WHAT DOES IT SAY ABOUT ITSELF?
      find Documentation -ipath '*<name>*' | head -20
      Read the overview .rst before any .c file. In-tree docs ship with the code
      they describe and are reviewed with it; a blog post does neither.

 3. WHAT ARE THE NOUNS?
      rg -n "^struct [a-z_]+ \{" <dir>/*.h include/linux/<name>*.h
      A subsystem is 3-6 core structs and the relationships between them.
      DRAW THEM before reading any function. If you cannot draw it, you have
      not found the core structs yet -- keep looking.

 4. WHAT ARE THE VERBS?
      rg -n "struct [a-z_]+_ops \{" -A 30 <dir> include/linux/
      Function-pointer tables ARE the architecture. For each one ask: who fills
      it in, who calls through it, and what is the contract?

 5. FOLLOW ONE PATH ALL THE WAY DOWN.
      Pick an entry point -- a syscall, a probe(), an interrupt handler -- and
      follow it to the hardware or to the return. ONE path, completely. Depth
      beats breadth on the first pass, every time.

 6. WHAT IS MOVING?
      git log --oneline --since="6 months ago" -- <dir> | head -30
      Recent churn tells you what is contentious, what is being rewritten, and
      what is dead. Reading thirty commit subjects is twenty minutes and it is
      the best twenty minutes you will spend.

 7. HOW IS IT TESTED?
      ls tools/testing/selftests/ | grep -i <name>
      rg -l "kunit" <dir>
      Tests are executable documentation of the contract, and gaps in them are
      contribution opportunities.

 8. WHAT COULD YOU NOT ANSWER?
      Write down three questions the tree could not answer. Phrase them well
      enough to ask on the list. That list is your entry point to the community.

Tip: Do not read a subsystem front to back. You will spend two weeks and retain a vague map. Steps 3 and 5 — the nouns, then one path — produce a usable model in a day, and everything else attaches to it afterwards.

The Eight Domains

Reading order for the survey

Do the four in this section first — they are the ones every other subsystem touches. A graphics driver allocates memory, sleeps, takes interrupts, and DMAs; understanding memory and the scheduler makes it readable. The reverse is not true.

Choosing One

Depth in one subsystem is what makes you useful. Breadth across eight is what lets you tell which one. Spend a week on the survey and then commit.

The criteria that actually predict success, in order:

Warning: Do not choose the subsystem that sounds most impressive. Choose the one where you can plausibly get a patch merged this quarter. A merged patch in drivers/firmware/ teaches you more than eight months of reading mm/ and sending nothing — and once you have the workflow and a maintainer who knows your name, moving to a harder area is much easier.

The honest difficulty ranking

Not a ranking of importance — of how hard it is to make a first contribution.

mm/ and kernel/sched/ are the two where a newcomer's patch is most likely to be correct and still rejected, because the bar is not correctness — it is "does this help enough to be worth the risk to every Linux machine in the world".

What a Good First Contribution Looks Like

Per-subsystem specifics are in each index.md. The general shapes:

And the shapes that reliably fail:

Section Structure

Each of the eight has the same shape:

Every subsystem chapter opens by making you run these two, because a table in a book goes stale and your tree does not:

git log --oneline --since="6 months ago" -- <dir> | head -30
./scripts/get_maintainer.pl -f <dir>

Deliverables

• The eight-step method applied to a subsystem you have never read, producing a written map another engineer could use.
• The same, timeboxed to two hours, on a second subsystem. (The gap between the two is the skill you just acquired.)
• All eight orientation chapters read; one sentence each on what it does and where it lives.
• One chosen, with a written justification against the five criteria.
• For your chosen subsystem: all concept chapters read with validation questions answered, and the labs done.
• One complete control path traced with ftrace or GDB, and your written trace matches the code.
• Subscribed to its list (or reading it on lore), and you can name three threads from the last month.
• Three plausible contribution targets, written down, each with why it is plausible and who owns it.

Validation / Self-check

1. Give the eight steps of the reading method in order, and say which two produce a usable model fastest.
2. Why nouns before verbs? Why one path before breadth?
3. What is the difference between MAINTAINERS ownership and actual activity, and how do you measure each?
4. Name the eight domains and, for each, one sentence on what it does and where its code lives.
5. Give the five criteria for choosing a subsystem, in order. Which one do people over-weight?
6. Why are mm/ and kernel/sched/ the hardest places to make a first contribution, given that the code is small?
7. Name four shapes of good first contribution and two that reliably fail.
8. For your chosen subsystem: what are its three to six core structs, and how do they relate?
9. What three questions could the tree not answer for you? Are they phrased well enough to ask?

Next: CPU and the Scheduler — start here even if you intend to specialize elsewhere, because everything else in the kernel is scheduled by it.