You want your LKML patch etiquette to help your changes land cleanly in the linux kernel without endless back-and-forth.

I know the submission process feels heavy at first — documentation, submit-checklist.rst, and driver notes all matter. We’ll show a clear, step-by-step path from local edits to well-formed patches that maintainers can review quickly.

Along the way I explain why preparing sensible patches and using git workflows reduces churn for you and other developers. Expect practical commands, short checklists, and the reasoning that helps your work get merged with less friction.

Key Takeaways

• Prepare changes as small, testable patches and follow the official process docs.
• Use git and unified diffs to create a clear history that reviewers trust.
• Include checklists and context so developers can bisect and test easily.
• Follow conventions for metadata and avoid sending patches as attachments.
• Polished submissions speed review and increase the chance of acceptance.

What LKML patch etiquette means for kernel developers today

When your changes arrive tidy and explained, reviewers can act instead of guessing. I focus on clear, practical habits that help kernel developers get through review queues faster.

Start by stating intent up front: what the change fixes and the user-visible impact. Use unified diffs and subject prefixes like [PATCH] so busy reviewers can sort mail quickly.

User intent: submitting patches the right way, right now

Keep each patch small and testable. A single logical change per commit means reviewers can apply and bisect without extra work.

Include a short problem statement, quantified impact, and any trade-offs. Add Fixes: tags or Message-Id links to show provenance and speed downstream routing.

Why etiquette impacts review speed and acceptance

Good habits cut ambiguity. Plain-text emails, correct threading, and proper recipients let maintainers quote inline and reply quickly.

1. Prefix subjects with [PATCH] and number series clearly.
2. Send unified diffs (git format-patch) and keep commits buildable.
3. Wait about a week before a polite ping; reviewers are often busy.

Setting up a clean Linux kernel development workflow

A reliable workflow begins with cloning the correct repository and keeping it current.

I start by fetching the upstream source with the canonical command:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (or use the https URL).

Many subsystems host their own trees — check the T: entry in MAINTAINERS to find the right base. For driver work, target that subsystem’s tip instead of always using mainline.

Clone strategy and branches

• Clone Linus’s mainline for general kernel development or the subsystem tree when maintainers request it.
• Keep one tidy branch per change so you can rebase or abandon work without polluting your main line.
• Rebase topic branches frequently with git rebase -i to split commits and keep history clean.

Keeping sources current

Pull early and often. Rebasing your topic branch on the latest tree reduces conflicts and helps reviewers apply your patches cleanly.

Creating high-quality patches that are easy to review

Small, buildable commits let reviewers and bisect tools find problems quickly.

I split logical changes so each commit does one thing—fix a bug, refactor a helper, or adjust an API.

Use git rebase -i to reorder, split, or squash until every commit compiles and passes basic tests. If you prefer, a quilt-style workflow enforces the same discipline.

Generate unified diffs the expected way

Produce your series with git format-patch so metadata is correct and maintainers can apply via git am.

Each commit message should wrap at ~75 columns, include a concise explanation, a Signed-off-by line, the — marker, and a small example when it clarifies intent.

Keep every commit buildable and bisect-friendly

• One logical change per commit avoids mixed intent and speeds review on lkml.
• Don’t mix whitespace cleanup with functional changes—send those as separate patches.
• Make sure the kernel builds and runs after each commit so git bisect can traverse the series.

For a fuller walkthrough of contributing and preparing changes, see our guide on how to contribute to the linux.

Commit and cover letter etiquette for the linux kernel mailing list

Start cover letters with a crisp problem statement and the concrete user impact. Lead with what breaks, who notices it, and the measurable benefit your changes deliver.

Use an imperative subject that begins with a subsystem prefix. Example: [PATCH 001/123] x86: reduce boot-time cache checks. Keep it short so mail clients and reviewers can scan the list quickly.

What to include in each message

• Open with the problem, user-visible impact, and trade-offs—quantify gains or regressions when possible (hardware, workload, numbers).
• Use Fixes: tags when relevant with the first 12 chars of the SHA and one-line summary. Example: Fixes: 1a2b3c4d5e6f – reduce cache checks.
• Reference related discussion using https://lkml.kernel.org/ and the Message-Id so threads remain linkable.

Format and hygiene

Wrap the body at ~75 columns, include a Signed-off-by line, then — and the diff. Always resend the full commit message for a new version—do not rely on earlier emails.

Style and linting: make checkpatch.pl your ally

I run a quick style pass before I prepare any series. It saves time and reduces fix cycles during review.

Follow Documentation/process/coding-style.rst

Keep the official documentation at hand and align your code with it. Consistent formatting helps reviewers focus on logic, not layout.

When to justify warnings and when to refactor

Use scripts/checkpatch.pl to scan your patches. It reports ERROR, WARNING, and CHECK so you know what to fix and what to consider.

• Fix ERRORs — they usually indicate real issues.
• Treat WARNING and CHECK as guidance; explain deviations in the commit message.
• When moving code, move first and refactor later in a follow-up so history stays clear.

Style is a tool, not a dictator. We focus on correctness first, then polish for reviewers on lkml and maintainers in the kernel community.

Finding the right recipients and lists for your patches

Targeted email beats broad blasts — find the right maintainer and list first.

I run scripts/get_maintainer.pl against the files my changes touch. It quickly lists responsible names and suggested mailing lists so my messages reach the right developers.

MAINTAINERS and subsystem mailing lists

The MAINTAINERS file confirms preferred contacts, trees, and lists. I follow those names and lists unless a maintainer asks otherwise.

When to use vger lists and special addresses

Only add linux-kernel@vger.kernel.org as a last resort. Avoid spamming unrelated lists with changes they don’t own.

• Keep a tight CC list and include developers who recently touched the code.
• Don’t send more than 15 patches at once to vger lists — stage big series or coordinate first.
• For exploitable security bugs, email security@kernel.org privately.
• For severe released-kernel fixes, add Cc: stable@vger.kernel.org in the commit trailer per stable rules.

LKML patch etiquette: sending email the acceptable way

Sending clean email saves reviewers time and keeps the review flow predictable. Treat sending as a clear step in your workflow: format, verify, and thread before you press send.

Plain-text inline only

We always submit patches inline in plain text—no MIME, no compression, no attachments. Plain messages let reviewers quote and comment directly in the body.

Follow Documentation/process/email-clients.rst to configure your mailer so it does not mangle whitespace or wrap diffs. If a tool corrupts content, fix the setup before sending.

Subjects and threading

Prefix subjects with [PATCH] and use versioned numbers like [PATCH v2 3/7]. That number format helps the mailing list sort and reviewers track progress.

For revised series, reply with an In-Reply-To header so the thread stays intact for reviewers, Patchwork, and bots.

git send-email and dry runs

Configure git send-email for your SMTP server. For example, Gmail uses smtp.googlemail.com with TLS on port 587; prompt for the password at send time rather than storing it.

Always do a dry run by sending the message to yourself first. View the email in a plain text client and confirm the diff, trailers, and Signed-off-by lines render exactly as intended.

Tooling that smooths the process: lore, patchwork, and b4

Good tooling turns inbox hunting into a predictable habit—search, fetch, and apply with fewer surprises.

I use lore.kernel.org to search the list by subject, author, or Message-Id. That view matches what maintainers and bots see, so I verify headers and threading there before I act.

Search and track threads on lore.kernel.org and Patchwork

Patchwork helps me watch state changes—New, Under Review, Accepted—so I don’t miss a maintainer pick-up. A Patchwork account makes it easy to see where my series sits.

Use b4 am to fetch, split, and apply series cleanly

b4 fetches a full thread from lore and auto-splits cover letters, patches, and commentary into a tidy folder. I run b4 am -o patches <Message-Id> and then apply with git am -i on the generated mailbox.

• b4 preserves trailers like Reviewed-by and Tested-by.
• It produces a ready-to-apply mailbox, so git am handles the work for you.
• Integrate b4 with your format-patch/send-email flow to keep inbound and outbound ways consistent.

Applying and testing patches from the linux kernel mailing list

Before I apply anything, I make a tidy directory and fetch the thread t.mbox.gz from lore.kernel.org. Then I extract it into a local patches directory so the files are easy to inspect.

I create a local topic branch and run git am -i to apply messages interactively. This gives me control when a message needs manual review or fixes for context drift.

Download, extract, and apply

• Create a topic branch: git checkout -b topic/series-name.
• Download the thread mbox.gz from lore, extract into a patches directory and run git am -i patches/*.mbox.
• When git reports an empty message for a cover letter (0/N), use git am –skip and continue—this is normal.
• Review each file and commit in the interactive prompt before accepting; it helps catch subtle issues.

Order, dependencies, and tooling

Cover letters often document the intended order and dependencies. Follow that number order and fetch any prerequisite series first to avoid conflicts.

Using b4 to fetch a thread produces a cleaned .mbx that drops most non-patch messages. I then apply the .mbx with git am -i and expect fewer empty messages.

For a driver or arch-specific commit, I test-build the relevant config and run quick smoke tests. I document any issues back to the list if a message no longer applies cleanly.

Tags that communicate review state and collaboration

Explicit tags speed triage—reviewers can see a patch’s status at a glance.

I follow a simple rule: put accurate trailers at the end of the message body before the — marker so tools can parse them.

• Signed-off-by—one per author. It attests to the Developer’s Certificate of Origin and shows the delivery path.
• Co-Developed-by—add this with a matching sign-off when work was shared, and include each author’s Signed-off-by.
• Reviewed-by, Acked-by, Tested-by—include these exactly as provided. Spell each reviewer’s name and email to keep Patchwork and maintainers happy.
• Suggested-by and Reported-by—credit ideas and bug reporters to build goodwill among developers.
• Cc: lines—keep a tight list of interested names so the right people receive the email without adding noise.

Finally, I keep the thread intact for v2+ series and update the changelog under the trailers. Accurate tags help kernel developers and other developers assess a set of patches quickly and route them to the right tree.

From first submission to merge: patience, pings, and professional follow-ups

Submitting patches is only the first step in the kernel development process. After I send a series, I wait—comments usually arrive within a week. During merge windows or busy times, replies can take longer.

I track state with Patchwork and lore.kernel.org so I don’t guess when a branch picks up my work. If I haven’t heard back after about a week, I send one concise ping in the same thread and summarize what changed.

Keep your branch rebased and be ready to resend as [PATCH v2] with fixes or test updates. For bug follow-ups, acknowledge feedback, refresh trailers like Reviewed-by, and document fixes below the — line.

Avoid escalation to Linus for routine work. Work the subsystem tree, stay patient, and keep emails short and helpful until merge.