The source tree, not a normal GitHub project
torvalds/linux is the Linux kernel source tree as most developers encounter it on GitHub. The repo is famous enough that the page can look deceptively familiar: stars, forks, files, commits, and a README. That familiarity is the trap. Linux kernel development does not behave like a typical GitHub project where you open an issue, send a pull request, and wait for a maintainer button click.
The README points readers back to kernel.org, kernel documentation, lore.kernel.org, Bugzilla, the MAINTAINERS file, and role-specific docs. That is the right mental model. GitHub is a useful browser and clone target. The real development process is distributed across maintainer trees, mailing lists, subsystem rules, signed-off patches, review threads, stable branches, and downstream vendor trees.
Use this repo when you need mainline kernel source, want to inspect implementation details, want to build a local kernel for testing, or need a reference point for a patch discussion. Do not treat it as a support forum, package manager, or distribution kernel source for your laptop.
What is in the tree
The repository is the kernel itself: architecture code, drivers, filesystems, networking, memory management, scheduler code, security hooks, userspace APIs, tracing, tests, build scripts, and a large Documentation tree. The primary language is C, with assembly, Rust support, scripts, build metadata, and generated documentation sources around it.
The README is short because the tree is the artifact. It sends different readers to different doors. New kernel developers start with the development process, submitting patches, coding style, kbuild, development tools, and kernel hacking docs. Researchers jump into memory management, scheduler, networking, filesystems, RCU, locking, and power management. System administrators get admin guides, kernel parameters, sysctl tuning, tracing, and performance security notes. Hardware vendors get driver APIs, device model docs, bus docs, device tree bindings, power management, and DMA APIs.
That role map is useful because the kernel is too large for a single tour. The first good question is not “where is the code?” It is “which subsystem and which maintainer process am I entering?”
Building a kernel from this source
There is no app install step. You build the kernel, and doing that touches your boot path, modules, firmware assumptions, and sometimes Secure Boot policy. The in-tree guide Documentation/admin-guide/quickly-build-trimmed-linux.rst is the practical entry point for a trimmed test kernel.
The guide tells readers to prepare for Secure Boot restrictions, install build requirements such as compilers, Git, OpenSSL headers, bc, bison, flex, pahole, Perl, binutils, and libelf headers, and keep enough disk space for sources and build artifacts. It then walks through cloning a current kernel tree, creating a configuration from the running system, building with make, installing modules and the kernel, and rebooting.
For a first pass, the important targets are make localmodconfig, make olddefconfig, make htmldocs, make modules_install, and make install. The exact commands vary by distribution and machine policy, so copying a snippet without reading the guide is a bad trade. On Debian, Arch, systems using Secure Boot, and machines with unusual hardware, the details matter.
Contribution flow is not GitHub-first
The kernel patch process is built around email and maintainers. Documentation/process/submitting-patches.rst tells contributors to obtain a current source tree, understand the relevant subsystem, describe the problem, explain user-visible impact, quantify performance or size claims, split logical changes into separate patches, and send work to the right maintainers and mailing lists.
The MAINTAINERS file is not a ceremonial list. It maps files and subsystems to maintainers, mailing lists, review channels, status labels, source trees, bug trackers, and patchwork instances. Many subsystem maintainers expect patches against their own trees rather than directly against Linus Torvalds’ mainline tree. That is why a GitHub pull request against torvalds/linux is usually the wrong primitive for real kernel work.
This also explains the misleading GitHub issue count. As of 2026-06, the local snapshot shows only 3 open GitHub issues. That does not mean the Linux kernel has only three active problems. It means the issue tracker on this mirror is not the center of kernel work.
AI coding assistants have explicit rules
The current README has a dedicated entry for AI coding assistants, pointing to Documentation/process/coding-assistants.rst. That document is unusually direct. AI tools must follow the normal kernel development process. Contributions must satisfy the kernel licensing rules. AI agents must not add Signed-off-by tags because only a human can certify the Developer Certificate of Origin. The human submitter must review the code, take responsibility, and add their own sign-off.
That is worth spelling out because generic coding assistants often learn GitHub habits from smaller projects. The kernel process is more legalistic and more traceable. If AI helped, the docs describe an Assisted-by tag format. Basic tools such as Git, compilers, make, and editors are not listed there.
Mainline versus vendor and distro trees
torvalds/linux is mainline source. It is not the same thing as the kernel your distribution ships after config choices, backports, patches, module policy, signing, and release engineering. It is also not the same as a vendor tree such as Raspberry Pi’s Linux tree or Microsoft’s WSL2 kernel tree, which carry platform-specific changes and release constraints.
| Repository | Stars | Scope | Use when |
|---|---|---|---|
| torvalds/linux | 236,054 | Mainline Linux kernel source | You need upstream source, history, docs, or a base for kernel work |
| raspberrypi/linux | 12,931 | Raspberry Pi kernel tree | You need Pi-specific kernel builds and platform changes |
| microsoft/WSL2-Linux-Kernel | 10,445 | Linux kernel source used by WSL2 | You are studying or debugging the WSL2 kernel variant |
| zephyrproject-rtos/zephyr | 15,572 | Embedded RTOS project | You want a small-device RTOS, not the Linux kernel |
Counts are GitHub snapshots from 2026-06. The comparison is about role, not prestige. Mainline is the upstream reference. Vendor and distro trees are where product constraints land. RTOS projects solve a different class of embedded problems.
Where this page is most useful
For reading code, start from a subsystem rather than a top-level directory. If you care about filesystems, networking, memory management, scheduler behavior, drivers, or security, use the documentation index and MAINTAINERS file to find the relevant area. Then read code with that subsystem’s patch flow in mind.
For building, use the trimmed kernel guide before touching bootloader settings. For contributing, read the development process and submitting patches docs before preparing any change. For bug reports, follow the reporting guide rather than opening a random GitHub issue.
The star curve confirms the repository’s public visibility, but it says little about development health. Linux’s real health is visible in release cadence, subsystem review, mailing list traffic, stable maintenance, downstream adoption, and the fact that vendors and distributions keep building on it. GitHub stars are a map marker, not the project pulse.
Related
For systems learning by rebuilding small versions of real tools, codecrafters-io/build-your-own-x includes operating system and low-level projects. For broader developer learning paths, nilbuild/developer-roadmap is a higher-level map. For architecture tradeoffs above the kernel layer, donnemartin/system-design-primer is the better companion.
FAQ
Is torvalds/linux the official Linux kernel repository? It is the mainline Linux kernel source tree on GitHub, associated with Linus Torvalds’ tree. Kernel.org and lore.kernel.org remain central entry points for source, releases, docs, and development discussion.
Can I submit a GitHub pull request to Linux? For normal kernel work, no. Read Documentation/process/submitting-patches.rst, find the right maintainers through MAINTAINERS, and use the mailing list based process expected by the subsystem.
How do I build the Linux kernel from source? Read Documentation/admin-guide/quickly-build-trimmed-linux.rst. It covers build dependencies, configuration from your running system, kernel build targets, module installation, bootloader details, and distribution-specific traps.
Why are there so few GitHub issues? The GitHub issue count is not the kernel’s real bug queue. Kernel reports and review happen through Bugzilla, mailing lists, maintainer channels, downstream trackers, and subsystem-specific workflows.
What license does the Linux kernel use? The top-level COPYING file states GPL version 2 only with the Linux syscall note, and points to the in-tree license rules for files that carry other compatible notices.