Picture a building with two staircases running between every floor, both fully maintained, both lit. Tearing one down looks like nothing from the street. It is actually a quiet admission that the building got complicated for no reason, and the team in charge would rather live with the disruption than keep paying for the redundancy. The kernel doing exactly that with one of its internal random number helpers is the kind of story that does not show up in your daily workflow, which is exactly why it earns a slow read.
For more than a decade the kernel offered two separate ways for code running inside the kernel to ask for random bytes. The older route was a small library of functions called crypto_rng, sitting in front of the underlying generator. The newer route is built around helpers like get_random_bytes(), get_random_u32(), and get_random_u64(), and almost every freshly written driver uses these directly. Both paths still ship. Both still work. The patch series circulating on the kernel mailing list right now is the maintainers saying out loud that keeping both alive costs more than it saves, and the older path needs to go.
User space, the layer your programs actually live in, never touched crypto_rng. Your browser, your shell script, your database, your Python code, and your Go service all reach the kernel through /dev/urandom and the getrandom() syscall, neither of which is going anywhere. The retirement affects one of two internal doors behind a wall nobody outside kernel development had any business knocking on.
What the redundancy was actually costing
Kernel work has a peculiar shape. Every interface that exists is a tiny perpetual tax on the people who maintain it and on the people learning it. Documentation drifts. Test coverage drifts. New contributors spend their first weeks figuring out which of two paths to use for a task that ought to have one answer. Code review gets slower because reviewers have to keep both paths in their head.
The wrapper API in question earned its keep back when the underlying random number generator was younger, and driver authors wanted a generic front door that hid the implementation details. By now that front door is the thing that adds friction without adding clarity. The underlying generator is faster, better tested, and used almost everywhere. Keeping the wrapper means teaching every new contributor two ways to ask for the same bytes, and catching the same bug twice when somebody reports it in the older path.
There is a pattern in good software that goes like this. When two routes converge on the same outcome, you get to keep both only as long as the second one is pulling its weight. Once it stops, the honest move is to retire it. Pretending the second route still matters because removing it would be politically inconvenient is how codebases grow moss.
The bigger cleanup arc this fits into
This kind of pruning is not a one-off event. The kernel’s cryptographic internals have been contracting for years, with the same shape repeating across release cycles. Additions land when they earn their place, and removals land when they stop earning theirs. Internal surfaces flatten. New contributors learn less before they ship their first useful patch. Duplicate paths to the same outcome get collapsed into one.
You can spot the same trajectory in other kernel subsystems, including scheduler consolidation work the kernel team has been pushing through recent cycles, where parallel implementations that had grown side by side over the years finally got unified. The kernel is not shrinking because the maintainers ran out of ideas. It is shrinking because they decided a smaller, cleaner base compounds better than a larger, messier one with the same surface.
A few signals worth tracking over the next several release cycles:
- Internal helper APIs are getting shorter, with fewer layers between driver code and the actual generator.
- New contributor ramp-up time is going down, partly because there is less to learn before you understand the call path.
- Parallel implementations of the same primitive are being collapsed, not preserved “in case somebody needs them.”
- Stability and predictability of internal behavior are being treated as features, even when they cost you the ability to change behavior later.
I keep coming back to the living-thing analogy because it fits. Software that lives is software that sheds. Software that is treated as a monument is software that accretes moss until the path between front door and back door disappears.
What this means at your keyboard
If you run Linux on a laptop, a workstation, a home server, or a Raspberry Pi, the honest answer is that nothing changes for you. The interfaces you and your programs use are not moving. The cleanup happens behind a wall you never had to touch. If anything, your system gets slightly more boring in a good way, which is the highest compliment a kernel change can earn.
If you maintain your own out-of-tree kernel module, this is the moment to grep your source for crypto_rng and see what comes back. Anything you find either needs to move to the underlying primitives or to one of the modern helpers. The kernel’s own tree has already done that work. The lag is almost always in third party modules that nobody has touched since the early 2020s.
What to actually watch for, in practical terms:
- The kernel release that carries the change into stable, which is when distributions will start shipping it.
- The release notes from your distribution when it bumps to that kernel, especially any deprecation warnings about the older helper.
- Your own out-of-tree modules if you maintain any, particularly anything dormant that has not been touched in a few years.
- Vendor driver notes for any specialized hardware that ships its own module, since those lag the longest.
For most readers, the right action is exactly none. Let your distribution bump the kernel on its own schedule. Reboot when it asks, run the apps you actually use, and get on with your week. That is the entire point of a clean removal.
The costs that do not show up in your workflow
There is a real bill being paid here, even if end users never see it. Driver authors who still rely on the older helper have to port their code. Third party kernel modules, including proprietary drivers and a handful of specialized pieces of hardware support, may not get ported for months or years. If you depend on a niche driver that has not been updated in a long time, this is exactly the kind of change that exposes that lag, and you will find out the hard way.
There is also the human side. Maintainers of small subsystems have to spend cycles porting code that worked fine yesterday, and that is genuinely annoying, and pretending it is not would be dishonest. The upside is that the kernel ends up leaner, easier to audit, and easier to bring new contributors into. Most of the developers I have read on this topic seem to think that trade is worth it, and I lean the same way, but nothing here is free.
The third trade-off is opportunity cost. Cleanup cycles compete with feature cycles for maintainer attention. Every patch series that lands a removal is a patch series that did not land something else. The defense of that trade is that maintainability is the feature, and it pays back over years rather than in the next release notes.
What to watch, if you want to follow the story
The kernel mailing list is where the actual technical arguments happen. Phoronix is where the plain English summaries show up first. The kernel.org patch tracker will eventually show you the diffs once they are merged. When the change makes it into a mainline release and then into a distribution kernel, the patch series itself is a clean read for anyone curious how a careful removal gets staged, reviewed, and merged across several release cycles.
For most of you, the right move is still exactly nothing. Let your distro bump its kernel on its own schedule. Reboot, run the apps you actually use, and get on with the rest of your week. When a cleanup of this size touches nothing you have to think about, that is the cleanest possible outcome.
Bottom line
The kernel retiring a redundant helper is one of those quiet stories that looks like nothing and is actually a sign of health. When a project as critical as Linux is willing to remove working code, that tells you the maintainers trust their tests, trust their process, and care about clarity more than about looking busy. Pay attention the next time you see a kernel cleanup that sounds boring. That is usually where the real engineering judgment lives.