Microkernel approach in minix3

In computer science, a microkernel is the near-minimum amount of software that can provide the mechanisms needed to implement an operating system. These mechanisms include low-level address space management, thread management, and inter-process communication (IPC).As an operating system design approach, microkernels permit typical operating system services, such as device drivers, protocol stacks, file systems code, to run in user space.MINIX3 has around 4,000 lines of code. Kernels larger than 20,000 lines are generally not considered microkernels.


Reflecting on the nature of monolithic kernel based systems, where a driver (which has approximately 3-7 times as many bugs as a usual program) can bring down the whole system,MINIX3 aims to create an operating system that is a "reliable, self-healing, multiserver UNIX clone".In order to achieve that, the code running in kernel must be minimal, with the file server, process server, and each device driver running as separate user-mode processes. Each driver is carefully monitored by a part of the system known as the reincarnation server. If a driver fails to respond to pings from the reincarnation server, it is shut down and replaced by a fresh copy of the driver.In a monolithic system, a bug in a driver can easily crash the whole kernel, something that is much less likely to occur in MINIX3.



Reliability factors in MINIX3 :-

Reduce kernel size
Cage the bugs
Limit drivers' memory access
Survive bad pointers
Tame infinite loops
Limit damage from buffer overruns
Restrict access to kernel functions
Restrict access to I/O ports
Reincarnate dead or sick drivers
Integrate interrupts and messages

Architecture :


The approach that MINIX 3 uses to achieve high reliability is fault isolation. In particular, unlike traditional OSes, where all the code is linked into a single huge binary running in kernel mode, in MINIX3, only a tiny bit of code runs in kernel mode about 4000 lines in all. This code handles interrupts, process scheduling, and interprocess communication. The rest of the operating system runs as a collection of user-mode processes, each one encapsulated by the MMU hardware and none of them running as superuser. One of these processes, dubbed the reincarnation server, keeps tabs on all the others and when one of them begins acting sick or crashes, it automatically replaces it by a fresh version. Since many bugs are transient, triggered by unusual timing, in most cases, restarting the faulty component solves the problem and allows the system to repair itself without a reboot and without the user even noticing it. This property is called self healing, and traditional systems do not have it.

An Approach to core dump in minix3

Hey people,
I have been trying to work around implementing core dump in minix3.A clear understanding of what core dump is necessary for its design. I will start with what a core file is.

The core file contains the memory image of the process, which can be used for debugging purposes.A core file is created when various errors(depends on how dumping is implemented) occur. Errors such as memory-address violations, illegal instructions, bus errors, and user-generated quit signals, commonly cause this core dump. The core file that is created contains a memory image of the terminated process.

The contents of a core dump are organized sequentially in the core file.It may follow any data structure to produce dump.Below is a rough idea of what things can be included.

Core header -> Defines basic information about the core dump, and contains offsets that locate the remainder of the core dump information.
User stack -> Contains a copy of the user stack at the time of the core dump.
Data area -> Contains the user data section.
Memory mapped regions -> Contains the anonymously mapped regions.

Process Control Blocks :

A process control block (PCB) exists for each process, describing the state of that process by maintaining the LDT, as well as saved register values, used to save the process state while a process is waiting to be scheduled. The PCB is a struct proc, containing important information about one process, including the process number and status. Also accessible through the PCB, via the p_map memory map, are the base addresses and physical and virtual sizes of the three segments of each process: (1)the text, (2)data, and (3)stack segments.

In minix architecture the microkernel, file system, and memory manager all maintain their own process tables but keep strict correspondence between these entries.The complete state of a process is defined by the process' data in memory, plus the information in its process table slot.