3 ms·
To be clear, this is about the internal implementation in the kernel, the mmap() system call is not going anywhere.
by Denvercoder9 1y ago
To be clear, this is about the internal implementation in the kernel, the mmap() system call is not going anywhere.
- K0IN 1y agothank you that was the first thing I had to check.
- porridgeraisin 1y ago"We do NOT break userspace"
- aa-jv 1y agoI'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 1y agoIn 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 1y agoThe mmap syscall operates on files so it's still very easily misinterpreted
- deleted 1y ago[deleted]
- commandersaki 1y agoWhich 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.
- arp242 1y agommap 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 1y agoIndeed. 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 1y agoYes, 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?