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).
Subscribe to:
Post Comments (Atom)
Hi, again! I have three questions.
ReplyDelete1. With reference to the figure 2-46 (a) in the MINIX book (Page 203,section 2.7: System Task) it is clear that after a hardware interrupt is received, the system task sends a message to the driver which makes the driver runnable again. Does it mean that before the interrupt the system task was blocked?
2. A driver registers its interrupt handler by providing the address of the handler to the system task. This handler is automatically called when a hardware interrupt occurs. When a hardware interrupt occurs the mode is automatically changed to kernel mode and eventually the respective interrupt handler is run. The problem is: this interrupt handler is provided by the driver. so is it safe to run it in kernel mode?
3. In MINIX it is repeatedly said that hardware interrupt results in a message to the driver process which is then marked as runnable. I am unclear as to the "source" of this message. Who sends this message? It is said that interrupt handler posts this message. Interrupt handler is considered part of which process (as source id is required for posting a message)? Does interrupt handler post this message to system task (which is up to this point blocked waiting for message) which in turn posts the message to the driver process.
--------------
It seems I am missing some thing. Thanks in advance.
Hi, I will get back to you. I have been busy.
Delete