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.
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`.
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.
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?
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.
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?
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
>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!
To be clear, this is about the internal implementation in the kernel, the mmap() system call is not going anywhere.
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.
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`.
The mmap syscall operates on files so it's still very easily misinterpreted
thank you that was the first thing I had to check.
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.
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?
"We do NOT break userspace"
_shifty eyes over at cgroups_
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
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.
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?
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
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!