# Greg Kroah-Hartman

> 1973– · Programmer, Linux Kernel Developer
>
> **Recorded contribution:** Linux kernel stable maintainer; Linux driver model; USB subsystem

## How to use this dossier

Read for a causal chain, not a hero story: inherited problem → contribution → mechanism → downstream capability → limit. Then close the page and complete the reconstruction exercise from memory.

## 1. Historical orientation

Greg Kroah-Hartman is a long-serving Linux kernel developer associated with the stable kernel series, driver core, USB, staging, and release maintenance. His historical importance is less a single algorithm than a demanding maintenance boundary: integrating hardware support and security fixes into a kernel used across servers, phones, embedded devices, and personal computers.

## 2. The problem inherited

A fast-moving kernel must support changing hardware and accept thousands of patches without sacrificing compatibility, reviewability, security, or the ability to deliver fixes to older deployed versions.

## 3. The central contribution

Kroah-Hartman helped build Linux's driver model and became a principal stable-kernel maintainer, institutionalizing review and backport practices for widely deployed releases.

## 4. Reconstruct the mechanism

1. Represent devices and drivers through common kernel objects, buses, classes, and lifecycle rules.
2. Review subsystem patches in public trees before integration upstream.
3. Identify fixes suitable for stable branches without importing unrelated change.
4. Publish signed releases and coordinate downstream testing and adoption.

## 5. What changed downstream

- The driver model made heterogeneous devices more consistently visible to the kernel and user space.
- Stable maintenance provides a path for important fixes to reach deployed kernels after mainline development moves on.

## 6. Attribution, limits, and uncertainty

- Linux is the work of a vast contributor and maintainer network; no maintainer individually controls all code or downstream deployment.
- A stable backport can still regress hardware, and vendors may delay or omit updates; upstream release does not guarantee end-user security.

## 7. Reconstruction lab

Select one Linux stable patch. Trace it from mainline commit through stable nomination, review, release, and a hypothetical distribution update; list evidence needed at every handoff. Choose a patch with a prerequisite commit and test what happens when only the visible fix is backported. Distinguish a patch that applies cleanly from one that is behaviorally safe on an older branch. Build a small risk matrix using severity, regression probability, installed population, and test coverage. This turns “stable maintenance” into an engineering discipline of constrained change, where refusing or delaying a patch can be as consequential as accepting it. Include a rollback criterion and explain why rollback itself can fail after data formats or externally visible behavior have changed.

## 8. Evidence trail

- [Linux kernel maintainers](https://www.kernel.org/doc/html/latest/process/maintainers.html) — Linux kernel project
- [The Linux Driver Model](https://www.kernel.org/doc/html/latest/driver-api/driver-model/overview.html) — Linux kernel documentation
- [Greg Kroah-Hartman](https://www.linuxfoundation.org/about/fellows) — Linux Foundation

---

*Research checked 2026-08-09. Dates, roles, and claims about living people are historical snapshots. Linked sources remain the authority; this dossier is original instructional synthesis.*