The microkernel design of Minix

In a monolithic OS, the entire OS is in a single process. But Minix has a microkernel design in which the operating system is composed of a set of processes (the kernel being just one of them) that work together by passing messages to each other. In this case it becomes necessary to distinguish between 'system calls' and 'kernel calls'. Unlike in a monolithic OS, user processes in Minix do not request services directly from the kernel. System calls from user processes result in 'messages' to the server processes (File System, Process Manager etc.). In turn, the server processes communicate with each other, the device drivers and with the kernel again using 'messages'. These messages to the kernel are really the 'kernel calls'. User processes do not have the privileges to make kernel calls.

In summary, the conventional 'system call' in Minix results in one or more 'kernel calls' which will be initiated by either the server processes or device drivers. The ipc primitives: send, receive and notify are the 'infrastructure' on top of which kernel and system calls are built. The technical term for these ipc primitives is 'traps'.

Tanenbaum gives a nice analogy to drive home the meaning of traps in Minix. The ipc primitive is like a carrier wave in a radio communications system. A send message contains some data which conveys useful information to the receiving process. It is like a modulated radio wave. The notify message conveys no information other than its origin. This is like an unmodulated radio wave (like a radio beacon that guides airplanes to an airport).

The Minix Process Table

The complete state of a process is defined by the process' data in memory, plus the information in its process table slot. See picture for details.

Minix Kernel Data Structures

While studing the kernel data structures, it is a pain to go back and keep referring to the source in order to visualize the inter-relationships and references among the various pieces of data. I am currently working on some diagrams that will make it easier to visualize the layout of data in the kernel. I hope to upload these diagrams this weekend.

Have been busy

I have been busy for a few weeks. Work from my day job has picked up and I am short staffed. Too many night phone calls. Too many meetings. No time to do anything worthwhile. I hope to fix the staffing situation at my work place and then get back to Minix after that. It is a real bummer. I was on a roll.

The heart of Minix

The 'save' assembly function in /src/kernel/mpx386.s is really the heart of the Minix OS. Discovering and understanding this function is like finding the holy grail. 'save' does some magical things. It doesn't follow any rules. It lives in its own world :-)

Coding on bare metal

Went through the startup process in the Minix book again. It makes more sense now. The next section explains interrupt processing excellently. This is where we really begin to understand how the illusion of multiple processes is created.

vish is a little closer to looking normal

One of the good engineers I know found out why my shell is not able to deal with commands without absolute path names. The problem was that I was using the wrong flavor of exec. Now that I am using execvp, this issue is resolved. execvp searches for the executable in the directories that are listed in the PATH env variable. Thanks Linu.