ACM Home Page
Please provide us with feedback. Feedback
Design and development of MINIX distributed operating system
Full text PdfPdf (108 KB)
Source ACM Annual Computer Science Conference archive
Proceedings of the 1988 ACM sixteenth annual conference on Computer science table of contents
Atlanta, Georgia, United States
Page: 685  
Year of Publication: 1988
ISBN:0-89791-260-8
Author
K. S. Ramesh  Dept. of Computer and Information Science, University of Mississippi
Sponsor
ACM: Association for Computing Machinery
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 6,   Downloads (12 Months): 30,   Citation Count: 0
Additional Information:

abstract   index terms  

Tools and Actions: Request Permissions Request Permissions    Review this Article  
DOI Bookmark: Use this link to bookmark this Article: http://doi.acm.org/10.1145/322609.323152
What is a DOI?

ABSTRACT

Students and faculty of University of Mississippi are in the process of transforming MINIX into a truly distributed operating system. MINIX is a complete operating system and has all the components such as 1) Process manager, 2) Memory manager, 3) File manager, 4) Device drivers, 5) Inter process communication, 6) Real time clock, 7) General i/o, 8) Utilities, 9) State saver and 10) Timing service. Unlike major operating systems which are monolithic in structure, MINIX is itself a collection of processes that communicate with each other through message passing. The design of the MINIX distributed system involves the addition of a server process called NET to the existing operating system. The functionality of the NET server can be broadly classified into four major routines. They are: 1) the communication manager which transmits and receives the frames from the remote hosts through the HSLAN driver installed in kernel. It also performs the error detection and correction function and maintains the transmission protocol. 2) The interprocess communication manager which maps message buffer into the fixed size frames to be transmitted by the communication manager. It also has primitives such as request, reply, flow controlled send to initiate and maintain a virtual circuit with the remote system. 3) The resource manager which is employed as a child process of the NET server process holds the status of the network. It maintains information such as remote logical address, number of process running in each system, resources available at each site etc. 4) Finally, the network service manager which services the remote file request from the local process and also the local file request from the remote host. Addition of these components in the NET process would enhance the capabilities of the operating system and provide users access to remote file systems and remote resources and also enable users to exploit multiprocessor capabilities with the help of well defined algorithms and tools. To accomplish the transformation of MINIX the following changes have been made to incorporate the NET process. Modify a system tool called Build which patches the independent files bootblok, kernel, memory manager, file manager and init into the memory resident portion of MINIX. Build was modified so that one more component NET could be added to the MINIX image. These were non-trivial changes because in addition to combining the object module Build also puts the CS & DS for all these components at the beginning of kernel data space, so that kernel can load their memory maps in the proc table during system initialization. Increase the storage size in the kernel data space where the CS & DS of all the components are stored so that Build can install the CS & DS of NET. Assign and make an entry into the memory manager proc table so that NET could make system calls to the memory manager. Assign an entry into the file system proc table and assign the working directory, real uid, effective uid for the NET process. The NET process like other processes is designed such that it will continuously wait for and respond to messages from other processes. Initially, it will be blocked waiting to receive a message from any process. Modify the dump routine to display the status of the NET process. Finally, the NET process is designed to continuously wait for its service request messages from other processes. The NET process is structured in such a way that the type of request is resolved and switched into a table of service routines. On accomplishing the service request the process loops back to receive the next request, thus providing the foundation for the development of the internal NET routines discussed above.