Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/deelerdev/linux/llms.txt

Use this file to discover all available pages before exploring further.

The Linux kernel is developed almost entirely through email. There is no single forum or chat platform that serves as the primary hub — the mailing lists are where patches are posted, reviewed, debated, and accepted or rejected. Understanding how those lists work, and how to find the right one for your subsystem, is the first step to participating in kernel development.

​
Mailing lists

All kernel mailing lists are archived at lore.kernel.org. This is the canonical source for list archives and lets you read threads, search by author or subject, and link to individual messages. You can also reply to threads from the web interface if your email client is configured correctly. The main development list is linux-kernel@vger.kernel.org (LKML). Most subsystem-specific patches and discussions happen on dedicated subsystem lists and are only CC’d to LKML. Sending everything exclusively to LKML is discouraged — maintainers prefer to receive patches on the relevant subsystem list.

​
Finding the right list for your subsystem

The MAINTAINERS file in the kernel source tree lists the maintainer name, email, mailing list, and git tree for every subsystem, driver, and file in the kernel. To find the correct list and maintainer for a given file, use the get_maintainer.pl script: 
./scripts/get_maintainer.pl path/to/your/file.c
The script reads MAINTAINERS and outputs the addresses you should use on the To: and Cc: lines of your patch email.
Always run get_maintainer.pl before sending a patch. Sending to the wrong list means your patch may go unreviewed for weeks.

​
IRC

The #kernelnewbies channel on irc.oftc.net is the recommended IRC resource for developers who are new to kernel contribution. Experienced developers volunteer there to answer questions about the patch submission process, kernel internals, and development tools. 
Server:  irc.oftc.net
Channel: #kernelnewbies

​
Bug tracking

Hardware and driver bugs can be filed at bugzilla.kernel.org. Developers who use the kernel.org Bugzilla or any other subsystem-specific bug tracker are expected to follow the Code of Conduct in those spaces, just as on the mailing lists.
Many subsystems prefer bugs to be reported directly to their mailing list rather than through Bugzilla. Check the MAINTAINERS file or the subsystem’s documentation for the preferred reporting path.

​
Resources for first-time contributors

kernelnewbies.org maintains guides, a wiki, and a list of “easy” bugs suited to first-time contributors. The kernel community is aware that entry hurdles can be high and provides these resources specifically for that reason.

Kernel Newbies

Tutorials, a glossary of kernel terms, and a curated list of beginner-friendly tasks.

Mailing list archives

Browse and search every kernel mailing list thread at lore.kernel.org.

Bug tracker

Report and track bugs at the official kernel Bugzilla instance.

Latest kernel

Download the latest stable and mainline kernel releases from kernel.org.

​
Conferences

Two conferences are most closely associated with kernel development:
  • Linux Plumbers Conference — a developer-focused event that runs micro-conferences on specific subsystems and cross-cutting concerns. It is the primary venue for in-depth technical discussions among maintainers.
  • Kernel Summit — a smaller, invite-based gathering of core maintainers that typically co-locates with the Linux Plumbers Conference.
Both events produce public proceedings and session recordings that are useful even if you cannot attend in person.

​
Configuring your email client

Patches must be submitted as plain-text inline email — not as attachments and not formatted as HTML. Most developers use git send-email to send patches. On the receiving end, maintainers use git am to apply them.
1

Use git send-email

git send-email is the most reliable way to submit patches. Its man page covers configuration in detail. Before sending to a list, send a patch to yourself first and verify it applies cleanly.
git send-email --to=yourself@example.com 0001-my-patch.patch
git am raw_email.txt
git log -1
2

Configure plain text

If you use a traditional email client, disable HTML composition and automatic word-wrapping. The client must send patch text untouched — no tab-to-space conversion, no line-break insertion, no format=flowed.
3

Set the correct encoding

Configure your client to send in ASCII or UTF-8. Do not use PGP/GPG inline signatures on patch emails — they break the scripts maintainers use to apply patches.
4

Preserve threading headers

Your client must generate and maintain References: or In-Reply-To: headers so that patch series and review threads remain properly threaded in the archive.
Do not send patches with format=flowed. This setting causes unexpected line breaks that corrupt the patch and make it impossible to apply with git am.
The useplaintext.email site provides client-specific instructions for disabling HTML and configuring plain-text sending, and lists email clients that are known to work well for patch submission.

Build docs developers (and LLMs) love

Get started for freeTalk to us