Contributing to the Linux Kernel: Complete Beginner's Guide
The Linux Kernel Development Model
The Linux kernel is one of the largest and most active open source projects in history, with over 30 million lines of code spanning 20,000 files across networking, file systems, memory management, device drivers, and architecture-specific code for everything from supercomputers to embedded sensors. More than 8,000 unique developers contribute to each release cycle, producing approximately 15,000 patches from 2,000 developers across 100 subsystem maintainers. No single person understands the entire kernel — the project is organized around subsystem communities, each with its own maintainers, mailing lists, and conventions.
The kernel development process predates GitHub and modern collaborative platforms by over a decade. Unlike most contemporary projects, patches are submitted as formatted emails to public mailing lists, reviewed by subsystem maintainers and peers, and ultimately pulled by Linus Torvalds into the mainline tree. This email-based workflow, while unfamiliar to developers accustomed to GitHub pull requests, is remarkably effective at scale. The Linux Foundation offers free training courses specifically for kernel contribution, recognizing that the workflow is a significant barrier to entry for new contributors.
The Release Cycle
Each kernel release follows a predictable ten-week cycle. The first two weeks are the merge window, during which Linus accepts pull requests from subsystem maintainers for new features and significant changes. The remaining six to eight weeks form the release candidate phase, during which only bug fixes are accepted as the kernel stabilizes toward a final release. Long-term stable kernels are maintained by designated LTS maintainers who backport critical security and stability fixes for two to six years. Understanding this cycle is essential for timing your contributions — new features submitted during the release candidate phase will be rejected regardless of quality.
The Mailing List Workflow
Contributing to the kernel requires mastering the email-based patch submission workflow. Use git format-patch to convert commits into properly formatted email files, then git send-email to submit them to the correct mailing list. Each commit becomes a separate email with the diff as the body and the commit message as the email content. Subject lines require subsystem prefixes that identify which part of the kernel the patch affects: for example, [PATCH net-next v2] net: fix memory leak in socket buffer handling. Every patch must include a Signed-off-by line from the author and each person who handled the patch, establishing the chain of certification required by the Developer Certificate of Origin.
Send patches to the correct subsystem mailing list and explicitly CC the subsystem maintainer. Sending to the wrong list wastes everyone’s time and signals that you have not done your homework. Each kernel subsystem has its own mailing list and its own maintainer listed in the MAINTAINERS file at the root of the kernel source tree. Review this file carefully before submitting any patch.
Patch Requirements
Every kernel patch must meet specific requirements to receive a review. Patches need proper Signed-off-by chains that certify the contributor has the right to submit the code under the kernel’s license. Subject lines must include the appropriate subsystem prefix and a version tag for revised patches. New features must include kernel-doc documentation, a standardized markup format for inline kernel documentation. Patches must pass checkpatch.pl, the kernel’s automated style and common-mistake checker, with zero errors. Patches that fail checkpatch.pl are rarely reviewed — the tool is considered the minimum quality bar.
Kernel Coding Style
The kernel enforces a specific coding style documented in Documentation/process/coding-style.rst. Indentation uses tabs, not spaces, with each tab being eight characters wide. Line length is limited to 80 characters. Braces follow K&R style: opening brace on the same line for functions, on the next line for blocks like if, else, for, and while. Spaces go around most operators. Comments use the C89 /* */ style, not C99 //. The style is rigorously enforced — maintainers will reject patches that violate coding style even if the logic is correct. Running checkpatch.pl on every patch before submission is mandatory. The kernel’s coding style is not a matter of taste; it is a non-negotiable requirement for participation in the project.
Building and Testing the Kernel
Building the kernel requires downloading the source from kernel.org, configuring it, and compiling it for your target architecture. Start with make defconfig to generate a default configuration, then build with make -j$(nproc) to use all available CPU cores. Test your changes in a virtual machine using QEMU for quick validation before deploying on real hardware. QEMU boots a kernel in seconds and provides debugging tools that make it ideal for development and testing. Always test on real hardware before submitting patches that affect hardware support — VMs can mask timing-dependent bugs and hardware-specific behaviors.
The kernel test robot provides automated testing on thousands of hardware and software configurations, running every submitted patch through build tests, boot tests, and functional tests across architectures and toolchains. Kernel developers rely heavily on this infrastructure to catch regressions before they reach Linus’s tree. If the robot reports a failure on your patch, address it before asking for a re-review.
Understanding the Subsystem Maintainer Model
The kernel is organized into approximately 100 subsystems, each with designated maintainers listed in the MAINTAINERS file. Subsystem maintainers are the gatekeepers for their area of the kernel — they review patches, apply them to their subsystem tree, and eventually send pull requests to Linus during the merge window. Identifying the correct subsystem and maintainer for your patch is your responsibility as a contributor. Building a positive reputation with a subsystem maintainer by submitting clean, well-tested, properly formatted patches is the most reliable path to patch acceptance.
New contributors should start with subsystems that are specifically welcoming to beginners: staging drivers, which exist as a proving ground for new driver code; documentation fixes, which are always needed and require minimal kernel expertise; and adding device IDs to existing drivers, which follows a well-documented pattern. The kernel community has become more welcoming to new contributors over the years, but the high technical bar remains — expect rigorous review and be prepared to revise patches multiple times before acceptance.
Common Patch Rejection Reasons
Understanding why patches are rejected helps new contributors avoid the most common mistakes. The most frequent rejection reason is failing to run checkpatch.pl before submission — maintainers will not review patches that fail basic style checks. The second most common reason is submitting patches to the wrong subsystem or mailing list, which wastes everyone’s time and signals insufficient preparation. Patches that lack proper Signed-off-by chains are automatically rejected because they fail the Developer Certificate of Origin requirement. Patches submitted during the release candidate phase for features rather than bug fixes are rejected regardless of quality. Patches that introduce new warnings or break builds on any architecture are rejected because the kernel policy requires zero warnings across all supported configurations.
The best way to avoid rejection is to study recently accepted patches in your target subsystem. Mimic their formatting, commit message style, and level of documentation. Read the subsystem’s specific contribution guidelines if they exist. Engage with the subsystem community on the mailing list before submitting your first patch, asking questions about open issues or ongoing work. Subsystem maintainers are more receptive to patches from contributors who have demonstrated engagement and understanding of the community’s norms. A patch from a known contributor who has participated in discussions is reviewed more favorably than an identical patch from a complete stranger.
Getting Started as a Kernel Contributor
Read Documentation/process/howto.rst from beginning to end — it is the official guide for new kernel contributors and answers most common questions. Set up a development environment with the latest mainline kernel from kernel.org, a working toolchain, and QEMU for testing. Find beginner-friendly areas: the staging tree, documentation fixes, and simple driver additions. Subscribe to the linux-kernel mailing list and relevant subsystem lists to understand the community’s communication patterns and review standards. Start with small, well-scoped patches and be patient — the kernel development process is slower than most open source projects because the stakes are higher.
FAQ
How long does it take for a kernel patch to be accepted? Simple bug fixes are often accepted within a few weeks. New features going through multiple revisions can take six months to a year from first submission to inclusion in a mainline release. Patches submitted during the merge window are usually integrated faster than those submitted during the release candidate phase.
Do I need to sign a Contributor License Agreement to contribute to the Linux kernel? No. The kernel uses the Developer Certificate of Origin, which requires only a Signed-off-by line certifying that you have the right to submit the code. No legal agreement is required beyond that certification.
Which kernel subsystem is best for new contributors? Staging drivers, documentation improvements, and adding device IDs to existing drivers are consistently recommended as starting points. The staging tree exists specifically as a proving ground where new code can be improved before moving to a permanent location.
Can I contribute to the Linux kernel without knowing C? Yes. Documentation improvements, testing and bug reporting, translation of kernel documentation, and tooling contributions are all valuable ways to contribute without writing kernel C code. The kernel community welcomes diverse contributions.
How do I find a mentor for kernel development? The Linux Foundation’s mentorship program, Outreachy, and Google Summer of Code all offer structured kernel mentorship opportunities. Additionally, many subsystem communities informally mentor promising new contributors who demonstrate effort and aptitude through their initial patch submissions.
Related: Contributing to Open Source | Open Source Governance | Open Source Guide