The Phaseout of the Mmap() File Operation in Linux

Posted4 months agoActive3 months ago

chmaynard

110 points

24 comments

lwn.netTechstory

calmneutral

Debate

40/100

Linux KernelMmap() System CallFile Operations

Key topics

Linux Kernel

Mmap() System Call

File Operations

The Linux kernel is phasing out the mmap() file operation, but not the mmap() system call, sparking discussion about the implications and historical context of this change.

Snapshot generated from the HN discussion

Discussion Activity

Moderate engagement

First comment

Peak period

96-108h

Avg / period

Comment distribution24 data points

Loading chart...

Based on 24 loaded comments

Key moments

01Story posted
Sep 25, 2025 at 5:16 PM EDT
4 months ago
Step 01
02First comment
Sep 25, 2025 at 5:24 PM EDT
8m after posting
Step 02
03Peak activity
10 comments in 96-108h
Hottest window of the conversation
Step 03
04Latest activity
Sep 29, 2025 at 11:47 PM EDT
3 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (24 comments)

Showing 24 comments

Denvercoder9

4 months ago

4 replies

To be clear, this is about the internal implementation in the kernel, the mmap() system call is not going anywhere.

porridgeraisin

4 months ago

1 reply

"We do NOT break userspace"

sethops1

3 months ago

1 reply

_shifty eyes over at cgroups_

o11c

3 months ago

Or the numerous syscall breakages (2.4 to 2.6 was most notable, but there have been plenty before/since).

Or all sorts of things in /proc/ and /sys/.

And the sheer nastiness of PPID 0.

And ...

aa-jv

4 months ago

2 replies

I'm relieved, but also somewhat befuddled that someone would write such a shocking headline. It immediately had me reaching for the lkml archives to find out whats really going on.

denotational

3 months ago

2 replies

In its defence, the headline says "file operation" rather than "syscall", which makes it slightly less egregious: it's referring to `mmap` as a member of `struct file_operations`.

commandersaki

3 months ago

Which worked as intended; I first had a shock, did a double take, and realised there was nuance in file operation, read a little bit of the article and confirmed my suspicion it didn't have anything to do with the syscall.

dooglius

3 months ago

The mmap syscall operates on files so it's still very easily misinterpreted

arp242

3 months ago

mmap is POSIX, so it's not going anywhere and you can rely on it until POSIX systems are phased out or the heat death of the universe, whichever comes sooner.

ajross

3 months ago

1 reply

Indeed. But even so, it's mildly shocking, as struct file_operations has been one of the deepest (and most promiscuously) integrated and most conservative bits of the kernel API. This stuff dates back decades and almost never changes. And there are a lot of raw file drivers[1] still there from eras most people have forgotten about.

This is a big, big reorg even for Linux.

[1] To be fair, most of which probably don't support mapping.

kragen

3 months ago

Yes, that's true. However, it's a kernel-internal API, and those have never been considered stable, unlike the system call ABIs, which are mostly sacrosanct. Except for, like, uselib(). This is because pretty much all the code that calls the kernel-internal APIs is in a monorepo, so you can fix it all when you make the change.

Also, it's not that the core kernel is ceasing to provide a facility that drivers depended on; rather, it's ceasing to depend on a facility that drivers provided. But doing so involves adding this new mmap_prepare() thing, which is making the kernel depend on a new facility that drivers now must provide, I guess?

K0IN

4 months ago

thank you that was the first thing I had to check.

doubletwoyou

4 months ago

1 reply

That comment about how /dev/zero used to be used to allocate anonymous pages, anyone have more info? All I could find was a wikipedia article [0]

[0] https://en.m.wikipedia.org/wiki//dev/zero

jeffbee

3 months ago

2 replies

That's it, there isn't any more to know. When the ancient unixes first began to support anonymous maps, they were just hacked into existing code with "zero" as the file, because the only through-line in the unix family history is that the API must be as hideous as it needs to be to accommodate lazy system authors.

ars

3 months ago

1 reply

There is more to know, does the code special case this? Does it use the file name? Major minor number? Or does it actually read zero's from it and place them in memory?

convolvatron

3 months ago

it wouldn't be too hard to look at the source for mmap and zero, but since the topic of this article is the removal of the mmap 'virtual function' in the file, that would have been a pretty good place to throw a zero-page allocation

mort96

3 months ago

1 reply

Wait, by "allocating anonymous pages" we just mean memory allocation from the kernel that's used for implementing e.g malloc, right? Did memory mapped files come before memory allocation so that it "made sense" to implement memory allocation as "mapping in /dev/zero"?

Or was some amount heap memory always just mapped into the process in early UNIX so that the need to map more pages only appeared as programs started to demand more heap memory than whatever the standard amount was?

pdw

3 months ago

1 reply

In those days malloc would use sbrk to allocate memory. And yes, mmap was designed to memory map files. Using it to allocate anonymous pages came later.

mort96

3 months ago

Oh, I had never even heard of those syscalls before! Thanks, that makes sense.

DonHopkins

3 months ago

3 replies

I hope the new API is flexible enough to support my proposed /dev/seven, an infinite source of ^G.

https://news.ycombinator.com/item?id=17532285

>DonHopkins on July 14, 2018 | parent | context | favorite | on: The everything-is-a-file principle – Linus Torvald...

>I always wanted /dev/zero, which is used to mmap zeros into memory, to be more general and use the device minor number to define which byte gets mapped, so you could mknod /dev/seven with a minor number of 7, to provide an infinite source of beeps!

danudey

3 months ago

Can we also have /dev/bseven, which is the same thing but as a block device? Convenient if you ever want to be able to acquire ^G at larger scale, or randomly seek through your infinite ^G.

matja

3 months ago

CUSE on Linux can do that: https://libfuse.github.io/doxygen/cuse_8c.html

mort96

3 months ago

I want a /dev/yes. I'm tired of typing 'yes | apt install' etc. I want to type '</dev/yes apt install'. Just an infinite stream of "y\n".

drob518

3 months ago

Yea, that’s a clickbait headline. A lot less concerning once you read the first paragraphs.

View full discussion on Hacker News

ID: 45379196Type: storyLast synced: 11/20/2025, 12:29:33 PM

Want the full context?