Drop the question mark ...

In its original design, and up to version 3.0 distributed with the 3rd edition of his book (2005), Andrew Tanenbaum's MINIX was a single-address-space operating system. Granted, you could have multiple process running simultaneously and they're isolated from each other, but they all happily frolic in the same address space, and only the segmentation unit of the x86 processor prevents the havoc from happening.

It's not necessarily a bad thing: paging introduces overhead in address resolutions - especially when your virtual-to-physical translation buffer is no longer sufficient, requiring up to 3 cache misses before you get a single byte of data. Its impact on context switching is even more frightening than this: whenever you wake up another process, the whole translation buffer has to be flushed (okay, *some* pages -- usually those holding the kernel -- can remain sticky).

Not having paging has a huge impact, however: you can't build any sort of modern virtual memory. No partial swapping of some unused part of the software... and no "statistical allocation" of the memory. Much like in MS-DOS times, if your compiler *could* need up to 16Mo of RAM, you must give it all from the start. If it happens to need only 8Mo for the file you're compiling and that you need those other 8Mo for doing something else meanwhile, well, too bad for you.

But it has changed since then. Between 2008 and 2010, people have been adding a "virtual memory server" to Minix, which in turns remembers me of my "pager2" service in Clicker. It let you control mapping of your address space (do_mmap, do_mmunmap) and supports the process manager (do_fork, do_exit), but here, it also directly handle page faults through message passing. Again, it's very "memory object"-like (another key Clicker concept), which shouldn't be a surprise: I got the idea of the memory object while reading the other Tanenbaum book about operating systems :)

Altogether, I'm absolutely not convinced that placing the address space management into a server rather than into the microkernel was the best design choice one could make. Granted, 'forking a process' is something that could happen out of the microkernel, but pagefaults ? ...

Iirc, I had the idea of letting the Clicker microkernel know that some physical pages had been 'pre-allocated' to some memory object (which you can think of as 'virtual regions'), and only notify the server-level code about a miss when that pool is exhausted... a sort of hybrid micro/exo kernel. But I dropped the whole project before I got to that point.

One of my major "errors" regarding the Clicker overall design, though, was that will to make the paging optional, despite it turned out that every other feature was depending on it. My module mechanism allowed me to do so, but it over-complicated the whole code, introducing the need for sophisticated book-keeping structures, run-time service replacement, and a mysterious "private heap" feature where linker scripts should have been enough.