[comex]

The claim is inaccurate and mixes together multiple different things:

- The Mach microkernel originally supported true userland paging, like mmap but with an arbitrary daemon in place of the filesystem. You can see the interface here:

https://web.mit.edu/darwin/src/modules/xnu/osfmk/man/memory_...

But I'm not sure if Darwin ever used this functionality; it certainly hasn't used it for the last ~20 years.

- dynamic_pager never used this interface. It used a different, much more limited Mach interface where xnu could alert it when it was low on swap; dynamic_pager would create swap files, and pass them back into the kernel using macx_swapon and macx_swapoff syscalls. But the actual swapping was done by the kernel. Here is what dynamic_pager used to look like:

https://github.com/apple-oss-distributions/system_cmds/blob/...

But that functionality has since moved into the kernel, so now dynamic_pager does basically nothing:

https://github.com/apple-oss-distributions/system_cmds/blob/...

- The vast majority of kernel memory is wired and cannot be paged out. But the kernel can explicitly ask for pageable memory (e.g. with IOMallocPageable), and yes, that memory can be swapped to disk. It's just rarely used.

Still, any code that does this needs to be careful to avoid deadlocks. Even though userland is no longer involved in "paging" per se, it's still possible and in fact common for userland to get involved one or two layers down. You can have userland filesystems with FSKit (or third-party FUSE). You can have filesystems mounted on disk images which rely on userland to convert reads and writes to the virtual block device into reads and writes to the underlying dmg file (see `man hdiutil`). You can have NFS or SMB connections going through userland networking extensions. There are probably other cases I'm not thinking of.

EDIT: Actually, I may be wrong about that last bit. You can definitely have filesystems that block on userspace, but it may not be supported to put swap on those filesystems.

[krackers]

>xnu could alert it when it was low on swap; dynamic_pager would create swap files, and pass them back into the kernel

What's the benefit of this indirection through userspace for swap file creation? Can't the kernel create the swap file itself?

[comex]

Today the kernel does create the swap file itself. I don't know why it behaved differently in the past, given that the version of dynamic_pager I linked is only 355 lines of code, not obviously complex enough to be worth offloading to userspace. But this was written back in 1999 and maybe there was more enthusiasm for being microkernel-y (even if they had already backed away from full Mach paging).

[delusional]

Looking at some of the contemporary documentation it does look like it was essentially a historical accident. The interface it built to be all microkernel, but when it was adapted into a real system the microkernel concepts fell to the wayside as they were no longer useful, but where they didn't impose too much of a burden (as in the pager interface) they were allowed to stick around.

[95014_refugee]

For a long time we held the line on not having file operations originate from within the kernel (layering reasons). Eventually less sane heads prevailed.

[rollcat]

IMHO a kernel managing a file (any file) all on its own imposes too many assumptions about hardware and user space. This could unexpectedly bite you if you're in a rescue system trying to fsck, booting from external RO media, running diskless or from NFS, etc.

Meanwhile Linux allows you to swapon(2) just about anything. A file, a partition, a whole disk, /dev/zram, even a zvol. (The last one could lead to a nasty deadlock, don't do it.)

Perhaps the XNU/NeXT/Darwin/OSX developers wanted a similar level of flexibility? Have the right piece in place, even just as a stub?