This is a discussion on Microkernel architecture - Minix ; I'm slowly learning how Minix works. My first thoughts were that the microkernel business was about putting drivers in userspace and nothing more. "Because the file system, the process manager and all that stuff really have to go in to ...
I'm slowly learning how Minix works. My first thoughts were that the
microkernel business was about putting drivers in userspace and nothing
more. "Because the file system, the process manager and all that stuff
really have to go in to the 'classical' kernel, as they need close
integration between them", I thought.
My astonishment came when I heard that Minix put the filesystem and even
*the process manager* in userspace! The weirdness seemed even greater when I
heard that Minix indeed put some low lever drivers in kernel land. Clearly,
these two astonishments only showed that I was not prepared to understand
Now, I've just read a text about the Minix kernel API , and suddently
released that all those "kernel calls" aren't really served in the call
chain directly. In other words, although they are served by code that runs
in kernel mode, they are not executed as classical system calls are.
The only System Calls in the classical sense (that is, seved directly in the
requestor's call chain, possibly having been called by "traps") that Minix
has are the send/receive/sendrec/etc/etc, which are neither POSIX calls nor
Unix based calls in any sense. They only serve to support the "real", "app
visible" APIs, which are supposed to be implemented in userspace.
Then, the final answer to the question about putting the basic subsystems
(FS and PM) in userspace is that, in reality, the POSIX APIs are converted
to Minix messages in user libraries and sent to the respective processes.
Those processes in turn have copies of the kernel datastructures that
concern themselves and update those data structures in their own address
Meanwhile, they (the system servers) negotiate among them all the work that
usually has to be done to perform the requested call (exactly in the same
way as a monolithic one would do, but sending messages instead of calling
the functions directly). Finally, the involved servers send messages to
the "system" process, which makes the changes efective .
This seemed weird at first (and I guess Linus Torvalds thought the same 12
years ago), but now (some minutes after releasing this), I think I'm
beginning to like the design. After all, that's what Minix is all about:
design. The idea is not really being exceptionally fast, but instead being
reliable by using a singular design.
Now, putting PM and FS in the kernel seems a really bad idea for a
microkernel! Specially with a reasonably elegant alternative.
 Another point that I didn't release immediately was that the API of the
system task is not the POSIX API at all, although some of the calls (aka
message types) have similar names.
"Computer are composed of software, hardware, and other stuff terminated
in "ware", like firmware, tupperware, (...)" - by JJ.