How mmap() (system call) works

[clementttttttttt]

I can't really find information on how this works, and the Linux source is way too complicated.

[sj95126]

The current linux source is extremely complicated, but it might be worthwhile perusing one of the early sources. It looks like mmap first appeared in the 0.96 kernels.

[ggodw000]

I am studying kernel 2.6.x device driver book, mmap essentially maps device addresses to user address space in PAGE_SIZE granularity. Of course there are lot to it thou.

[iansjack]

Not just devices but, more generally, files.

But that's what it does, not how it does it.

[thewrongchristian]

I can't really find information on how this works, and the Linux source is way too complicated.

Have a look for BSD VM documentation. This is a nice overview: http://blog.pr4tt.com/2016/02/02/BSD-virtual-memory/

FreeBSD is based on the Mach VM subsystem used in 4.4 BSD.

NetBSD/OpenBSD replaced the Mach VM based subsystem with a simpler system called UVM but retains the Mach VM pmap interface to handle the CPU specific page mapping. It is described here: https://www.netbsd.org/docs/kernel/uvm.html

I find areas such as describing VM are better served by traditional text books. The "Design and Implementation of the FreeBSD Operating System" gives a good detailed overview of the FreeBSD VM, and should help in understanding how mmap is implemented.

I also find the BSDs VM subsystems are structured better than the Linux VM subsystem, which looks quite messy in comparison, and they tend to be better described in text books. I prefer the separation of hardware independent and hardware dependent layers via an API rather than the abstract page table data structure used by Linux.

TL;DR

Study the BSD VM subsystems. If you understand how they work, the mechanism of mmap should be simple. But you really need to know how VM works as a whole in order to understand mmap.

[iansjack]

I have an earlier version of the book that you mention (The Design and Implementation of the 4.4 BSD Operating System ) and I can heartily recommend it as an excellent explanation of the workings of an operating system. It was very expensive at the time I bought it (probably the most expensive book I had ever bought), but I note that the new version is much cheaper.

There are also a number of books explaining the Linux kernel, and the massive Mac OS X Internals, that are worth reading if you can find a copy. Much better than trying to understand any of these OSs by just reading the source.

I'm afraid that far too many people seem to plunge into OS development without doing any background reading - not even the essential programming manuals produced by the chip manufacturers. This is a huge mistake and just leads to reinvention of the wheel (or in most cases the invention of the square wheel). We can profitably build upon the experience of those who went before us. And a little research will hopefully do away with the situation where newbies come here with every single little problem that they hit along the way (the same old problems time and time again).

[thewrongchristian]

I have an earlier version of the book that you mention (The Design and Implementation of the 4.4 BSD Operating System )

Damn you! This prompted me to seek out and buy a copy of the original 4.3 BSD edition. This is the edition I read at University, and describes the VAX based virtual memory system.

[Schol-R-LEA]

As a rather belated aside to @clementttttttttt, is it reasonable to assume that you are building a Unix style kernel? While any other design will likely have something equivalent to mmap(), the specific system call and its operation will only really apply to a Unixoid system - a different type of OS might have a completely different memory model and implementation.

Given that you are using the Linux kernel for your research, I am guessing that a Unixoid kernel is your goal, but I wanted to be sure.

I ask this mainly because there's a possibility of an XY issue coming up here; it does you no good if we correctly answer the wrong question, after all.