[HN Gopher] The phaseout of the mmap() file operation in Linux
___________________________________________________________________
The phaseout of the mmap() file operation in Linux
Author : chmaynard
Score : 88 points
Date : 2025-09-25 21:16 UTC (4 days ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| Denvercoder9 wrote:
| To be clear, this is about the internal implementation in the
| kernel, the mmap() system call is not going anywhere.
| K0IN wrote:
| thank you that was the first thing I had to check.
| porridgeraisin wrote:
| "We do NOT break userspace"
| sethops1 wrote:
| _shifty eyes over at cgroups_
| aa-jv wrote:
| 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 wrote:
| 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`.
| dooglius wrote:
| The mmap syscall operates on files so it's still very
| easily misinterpreted
| ajross wrote:
| 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 wrote:
| 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?
| doubletwoyou wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Oh, I had never even heard of those syscalls before!
| Thanks, that makes sense.
| DonHopkins wrote:
| 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!
| mort96 wrote:
| 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".
| danudey wrote:
| 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 wrote:
| CUSE on Linux can do that:
| https://libfuse.github.io/doxygen/cuse_8c.html
___________________________________________________________________
(page generated 2025-09-29 23:01 UTC)