torvalds/linux: The Upstream Linux Kernel Development Repository
The Linux kernel source tree: the core of every Linux operating system, managing hardware and system resources and providing fundamental services for all other software.
At a glance
- What is it?
- The torvalds/linux repository on GitHub is the upstream source tree for the Linux kernel, currently at version 7.3.0-rc5. It is the authoritative entry point for kernel contributors, hardware vendors writing drivers, and distribution maintainers tracking the development branch.
- Who is it for?
- Kernel developers, hardware vendor driver authors, and distribution maintainers who need the current development tree are the audience for the torvalds/linux repository. Users who want to run Linux do not need to clone this repository; they should download kernel packages from their distribution or tagged releases from kernel.org.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 25, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What This Repository Is and Is Not
The torvalds/linux repository is not a distribution. It does not contain an installer, a package manager, or a user-space environment. It is the source code for the Linux kernel: the core component that manages hardware, allocates system resources, and provides the fundamental services on which all software running on a Linux system depends.
The repository is the mainline development tree. Changes accepted into this tree eventually reach Linux distributions through a downstream process: distributions take stable kernel releases from kernel.org, apply their own patches, and package the result. Developers who want to run Linux on a machine should not clone this repository; they should install a distribution.
The audience for this repository is specific: new kernel developers learning to contribute, academic researchers studying kernel internals, security engineers analyzing hardening features, hardware vendors writing drivers, distribution maintainers tracking upstream changes, and subsystem maintainers reviewing patches. The README organizes documentation entry points by each of these roles.
Repository Structure and Subsystems
The top-level directory layout reflects the kernel's internal organization. The arch/ directory contains architecture-specific code for every supported CPU architecture. The drivers/ directory holds device drivers, which is the largest subsystem by file count. The fs/ directory contains filesystem implementations. The mm/ directory holds the memory management subsystem. The net/ directory contains the networking stack. The kernel/ directory holds core scheduling, locking, and process management code. The security/ directory contains Linux Security Module implementations.
A rust/ directory is present in the top-level entries, reflecting the kernel's ongoing integration of Rust as a supported implementation language alongside C. The Documentation/ directory is extensive and is the primary reference for every subsystem. It covers memory management, the scheduler, networking, filesystems, RCU (Read-Copy Update), locking primitives, power management, driver APIs, and more.
The MAINTAINERS file at the top level maps every subsystem and file path to its current maintainer and mailing list. Patches must be sent to the correct mailing list for the affected subsystem. The get_maintainer.pl script, referenced in .get_maintainer.ignore, automates this lookup.
Building the Kernel from Source
The README directs users to Documentation/admin-guide/quickly-build-trimmed-linux.rst for the build process. The building requirements, including toolchain versions, are in Documentation/process/changes.rst. The Makefile at the repository root is the entry point for all build operations.
To see the full list of available build targets:
make helpThe kernel documentation can be built as HTML:
make htmldocsThe documentation build requires Sphinx and related Python packages. The resulting HTML documentation covers every API and subsystem in the repository and is also available online at kernel.org/doc/html/latest/.
Building the kernel itself requires a configured build environment. The configuration is generated by running one of the make *config targets (for example, make menuconfig for an interactive menu). The build then produces a compressed kernel image and modules. The specific output file names and locations depend on the target architecture.
The GNU Make minimum version requirement is 4.0, as enforced by an error check at the top of the Makefile: the build fails immediately with an error message if an older Make version is used.
Contributing: Patches via Mailing List, Not GitHub
The Linux kernel does not accept contributions through GitHub pull requests. The README describes the contribution workflow: patches are formatted as email and sent to the appropriate mailing list at lore.kernel.org. The Documentation/process/submitting-patches.rst file covers the complete process.
Every patch must include a Signed-off-by line (the Developer Certificate of Origin, described in Documentation/process/submitting-patches.rst). This is a legal attestation that the contributor has the right to submit the code and agrees to the license terms. Patches without a DCO are rejected.
The README includes a dedicated section for AI coding assistants, noting that LLMs and AI-powered development tools must read Documentation/process/coding-assistants.rst before contributing to the Linux kernel. This document covers requirements about licensing, attribution, and DCO compliance specific to AI-generated code.
After a patch is accepted by a subsystem maintainer, it enters a -next tree that acts as a staging area before Linus Torvalds merges it into the mainline during the next merge window, which opens after each -rc1 release.
Limitations of the Development Tree
The mainline tree is a moving target. Between the merge window and the final stable release of each kernel version, the code changes daily. Building from a random commit on the master branch can produce a kernel that is incomplete, unstable, or missing fixes that arrived in later commits.
The development tree also does not provide a stable API for kernel modules. The kernel explicitly does not maintain binary or source compatibility for modules across versions. A driver built against one kernel version may not compile or load correctly against the next. This is documented as intentional: out-of-tree drivers that are not merged into the mainline must be updated with each kernel release.
The GitHub interface provides read-only access to the repository. Issues opened on GitHub for the Linux kernel are not seen by the kernel development community, which communicates entirely through mailing lists. Bug reports should go to bugzilla.kernel.org or to the appropriate subsystem mailing list as described in Documentation/admin-guide/reporting-issues.rst.
Development Tree Versus the Stable Kernel Series
The torvalds/linux mainline tree is not what most distributions run. After a version stabilizes through several -rc releases, the final version is tagged and distributed at kernel.org. From that point, stable updates are handled by the stable kernel team, who backport security fixes and critical bug fixes to the stable branches. These are published at kernel.org/pub/linux/kernel/.
The stable series (for example 6.12.x or 7.0.x) is what Linux distributions base their kernel packages on. The difference in approach is significant: the mainline tree incorporates new features, new drivers, and API changes, while the stable series only adds bug fixes and security patches. Distribution maintainers tracking security vulnerabilities should monitor the stable series, not the mainline.
For kernel developers, this means the development workflow involves the mainline tree for new features and driver submissions, and the stable trees for security backports. The documentation for each path is different. Documentation/process/stable-kernel-rules.rst covers the stable tree process.
Maintenance and GPL-2.0 License
The last push to the repository was on 2026-09-25. The current development version is 7.3.0-rc5, named Baby Opossum Posse, as recorded in the Makefile. The repository has no GitHub releases; tagged releases are distributed through kernel.org.
The kernel is primarily licensed under GPL-2.0, as documented in the COPYING file at the root of the repository. The Makefile carries the SPDX-License-Identifier: GPL-2.0 header. The LICENSES/ directory contains the full text of GPL-2.0 and additional licenses covering specific components of the kernel that are licensed under different terms.
GPL-2.0 is a copyleft license: derivative works and works that incorporate GPL-2.0 code must themselves be distributed under GPL-2.0 when distributed. This is the primary license consideration for hardware vendors and embedded system developers who modify the kernel for their products.
Editorial conclusion
Kernel developers, hardware vendor driver authors, and distribution maintainers who need the current development tree are the audience for the torvalds/linux repository. Users who want to run Linux do not need to clone this repository; they should download kernel packages from their distribution or tagged releases from kernel.org. Before building the kernel from source, review Documentation/process/changes.rst for the exact toolchain versions required. The current development version is 7.3.0-rc5, code-named Baby Opossum Posse. The kernel is primarily licensed under GPL-2.0 as documented in the COPYING file; the LICENSES/ directory in the repository contains additional license texts covering specific components.
Frequently asked questions
What is Linux and why use it?
The Linux kernel is the core of any Linux operating system. It manages hardware, system resources, and provides the fundamental services that all other software depends on. The torvalds/linux repository is the upstream source tree that kernel developers contribute to, while end users run Linux through distributions that package the kernel with user-space tooling.
What is the difference between the torvalds/linux tree and the stable kernel releases?
The torvalds/linux repository is the mainline development tree where new features and drivers are merged. Stable kernel releases are separately maintained branches (such as 6.12.x or 7.0.x) that receive only bug fixes and security patches. Distributions and embedded systems typically use stable releases, not the development tree.
How do I submit a patch to the Linux kernel?
Patches are submitted as emails to the appropriate subsystem mailing list at lore.kernel.org, not through GitHub pull requests. Each patch must include a Signed-off-by line as required by the Developer Certificate of Origin. The Documentation/process/submitting-patches.rst file in the repository covers the full process.
Community notes