Implementation of a resource manager for distributed MINIX

Abstract

MINIX is an operating system written by Andrew S. Tanenbaum and is very much like UNIX Version 7. It uses the same system calls and even the shell is functionally identical to that of UNIX. It is written in C language and Intel 8088 assembly language. MINIX has all the functionalities of an operating system namely, process manager, I/O manager, device driver, state saver, inter-process communication, memory manager and file manager, user interface, utilities and timing service.MINIX, being a modular operating system, is easy to understand and modify and it is distributed with source code. Thus, MINIX can be identified as a suitable candidate for transforming it into a distributed operating system (DOS).To transform MINIX into a DOS, a kernel process called NET is proposed to be added. This will be logically located at the same hierarchical level as the memory manager and the file system. NET will be composed of a communication manager (CM), a network manager(NM), a resource manager (RM) and extended IPC. These managers will be transparent to users but will offer functionality of a DOS. At present, IPC in MINIX takes place using messages stored in shared buffers. This is due to the restricted address space of the Intel 8088 microprocessor. User requests are carried out by sending messages either to the memory manager or the file system which in turn send messages to the system and device driver processes and upon successful completion of the task, return a message to the user via the same route.The resource manager is an essential component of a DOS. As the name suggests, it manages the resources of a system. It maintains an up to date version of the system's resources and also keeps track of the status of other systems in the network. This is achieved by maintaining a global kernel data structure called the System State Table (SST). Entries in the SST include logical unit number of the various hosts, their logical names, physical station addresses, number of processes running, percent of idle time, available memory, number of users, number of open virtual circuits and an 'altruism' factor indicating willingness to accept remote processes for running. The SST may be accessed by the NM to map logical host names to numbers or physical addresses. The resource manager may be accessed by higher level components such as the user interface, linking loader or by advanced programmers by making resource manager service calls. In this way, the user interface and parallel loader query the RM to discover the number of available processors, willingness to accept remote requests, etc.The resource manager employs two types of messages: 1) messages are sent at boot time to all hosts announcing the present status of the local system including the boot version, and 2) a message is sent after each time-out interval. If a message is not received from a remote host after two time-out intervals, the remote node is presumed to be dead.The CM interacts with RM concerning the status information. This status information, piggy-backed onto message frames, is attached to incoming and outgoing frames.On incoming frames, the status information is placed in a temporary buffer for analysis by the RM. The RM also places local host status information in a second temporary buffer area so that the CM may piggyback the status data onto outgoing frames.