MINIX

What we will be covering!!!

History of MINIXOverview of the Minix Operating SystemThe Architecture of MinixThe Booting ProcessImplementation of System Calls – How it worksAn Insight into the securityConclusion

History of MINIXMINIX 3 has a bright future but somewhat checkered past. The first version, MINIX 1, was released in 1987 and was the first UNIX clone with all the source code available. It developed rapidly and soon had its own USENET newsgroup (comp.os.minix), with 40,000 subscribers within 3 months, a large number at a time when the Internet was only available to university researchers and students. One of the early MINIX adopters was a Finnish student named Linus Torvalds, who went out and bought a PC just to run MINIX, studied it very carefully, and then decided to write his own operating system, inspired by MINIX.

Although Linus knew MINIX very well, he didn't steal any code from it, as some people have alleged.Linus system grew into the modern Linux system. MINIX' author, Andrew Tanenbaum and Torvalds have had some fairly public discussions on operating system design, originally in 1992 and most recently in 2006.

Bird’s Eye View of MinixMinix – Mini Unix (Minix) basically, a UNIX -compatible operating system.Minix is small in size, with microkernel-based design.Minix has been kept (relatively) small and simple.Minix is small, it is nevertheless a preemptive, multitasking operating system.Internally, Minix is highly modular, consisting of several system processes organized into a number of independent programs.

Continuation…..

Full multiprogramming (multiple programs can run at once).Most of the code is written is C language and the source code is freely available.The initial implementation was for the IBM PC.Networking with TCP/IPThe MINIX 3 kernel is well under 4000 lines of executable code, compared to millions of executable line of code for Windows, Linux, FreeBSD and other operating system.

Internal Architecture

The figure represents the internal architecture of Minix.

User Processesinit, login, passwd, sh, ls, cp, cc,………..Server ProcessesFile System (FS), Memory Manager (MM)Kernel I/O TasksFloppy, tty, clock, system, …………Kernel Process ManagementInterrupt handlers

Different Layers4

3

2

1

Architecture Continuation…..There are 4 layers in the ArchitectureLayers 1 to 3 comprise the Minix operating system, with applications running in Layer 4.The operating system code is linked into three totally separate programs|mm (the memory manager), fs (the file system), and kernel (layers 1 and 2).Processes in layer 2 and interrupt handlers in layer 1 can communicate by message passing or shared memory; all other communication is through message passing.

Detailed Analysis of the Different Layers.

Layer 1(Kernel Process Management) implements communicating sequential processes, thus allowing the remainder of Minix to be implemented as a set of communicating sequential processes. Layer 1 is a group of interrupt handlers, with its own stack space within kernel.This layer also contains two modules that function similarly to device drivers.The clock task is an I/O device driver.System task

Layer 2 (Kernel I/O Tasks) contains device driver processes. System provides an interface between kernel and the layer 3 processes.The process in layer 2 have the most privileges. The process in layer 2 is called device drivers are allowed to request that the system task read data from or write data to I/O ports on their behalf.

Layer 3 (Server Processes) contains the memory manager and the file system.The 3rd layer contains server, process that provide useful services to the user processes.Two servers are essential:

Process Manager (PM) carries out all the MINIX 3 system calls.File System (FS) carries out all the file system calls, such as read, mount and chdir.

Other servers are Information Server, Reincarnation Server and Inet

Continuation…….

Layer 4 (User Processes) contains a Unix-like process hierarchy rooted at process 1. Every system call" made by a user process in layer 4 is converted into a message to one or other of these processes.Contains shells, editors, compilers and user written a.out programs.A daemon is a background process that executes periodically or always waits for some event.

Booting Process

The booting process is an important one in any operating system. Here in Minix, the bootstrapping occurs in the following way, A small SunOS program (minix) is responsible for processing a configuration file, allocating memory for SunOS Minix, loading and relocating the SunOS Minix \image" and then jumping to the startup code within the SunOS Minix kernel proper.In any case, the MINIX 3 boot program looks for a specific multipart file on the diskette or partition and loads the individuals parts into memory at the proper locations.This is boot image.

Continuation….

minix allocates the requested amount of memory in the data segment of the SunOS process, and loads the image, consisting of kernel, mm, fs and init, at the beginning of the area allocated.Booting has 2 phases

The minix PhaseThe kernel Phase

Booting Phases.Booting – the minix phase

The main functions of the minix program are,Read the configuration file, open various devices on well – known (to minix and kernel) SunOS descriptors.A child process is created that will run the Solaris minix.The child creates a temporary file that is the same size as minix physical memory and maps to child’s address space at the virtual address assigned to the beginning of kernel’s text segment.A bootinfo structure at the start of kernel data segment is filled in.Execution then switches to kernel entry point.

Continuation……

Booting – the kernel phaseThe kernel entry point is in a small piece of assembler code that sets the stack pointer to layer 1 stack, and then calls the C function “main”(main.c).Then the standard pieces of code that are added to the boot sequence involve the setting up the handling of SunOS signals, and setting up of memory protection.

Implementation of Process in MINIX 3

Organization of MINIX 3 source codeThe full path to the C language source code on a standard Intel-based platform is /usr/src/ .Makefile controls compilation of files in its directory and may also direct compilation of files in one or more subdirectories.The path for special case /usr/include/ System directory /src/servers/

Compiling and Running MINIX 3src/toolsThe simplest method is make image.To install a working MINIX 3 system capable of being booted, a program called installbootadds names to kernel, pm, fs, init and other components of the boot image.It is important to realize that MINIX 3 consists of several totally independent programs that communicate only by passing messages.

The common header filesThe include/ directory and its subdirectories contain a collection of files defining contants, macros and types.Header or include files identified by the suffix .hstdio.h; stdlib.h; a.out.h; sttdef.h

The MINIX 3 header filesInclude/minix/ and include/ibm contains header fiels specific to MINIX 3config.hsys_config.h contains definitions that are likely to be needed by a system programmer, for instance someone writing a new device driver.A fe of the definition in const.h are noteworthy.ipc.h are prototypes for the message passing primitives.com.h; devio.h; keymap.h;

Process Data Structures and Header fileskernel.h will defining three macrosconst.hm a macro for converting virtual addresses relative to the base of the kernel’s memory space to physical addresses.An important security mechanism built into the Intel hardware is activated by two macro definition.PSW – processor status word and IOPL (I/O Protection Level.type.h; proto.h; glo.h; Aout;

Bootstraping MINIX 3System initializationInterrupt handling in MINIXInterprocess communication in MINIX 3Scheduling in MINIX 3Hardware-Dependent Kernel SupportUtilities and Kernel Library

The Important Directory Structure

commandsfs – file systemkernel – kernel codessolaristoolsmm – memory manager

Flow OF control

The flow of control in minix from the user level the kernel level is handled by system calls.Minix has a set of system calls which are located in the table.c file. The fs has its own table and so the memory but the number of system calls is fixed

System Call

System call in minix is similar to a system, call in any system.A user-level process cannot directly access a disk. Instead it asks the kernel to obtain data from a file for it (the read system call). A user-level process cannot create another process. Instead, it asks the kernel to create one for it.

System call

System calls are typically made via library routines. Library routines are normal procedure calls. They perform the setup for the system call.In minix the system call functions in a similar fashion.

System call

To implement a system call in minix one needs to do the following steps.Look for a free slot in the table.c fileFollow the standard conventionno_sys, /* 0 = unused */do_exit, /* 1 = exit */do_fork, /* 2 = fork */

System CallThe system call would be named in the following manner

do_sandbox or do_encryptOnce the system call method has been written its declaration should be mentioned in the function declaration header file in the file system it is “proto.h”_PROTOTYPE ( return type do_XXXX, (arguments if any) );

System Call

The library should also be informed about the system call that would be called by the user.The library file for the system call is written in the lib/other directory. The file naming convention is followed here it starts with an underscoreEg: - _sandbox.c

System CallOnce the code for the system call is written in the "lib/other" directory a system file needs to be created. The system file is present in the "lib/sunsyscall" directory.A standard naming convention is followed here to. The filename extension is ".s".

.global systemcallnamesystemcallname:ba _systemcallnamenop

System Call

A system call will contain a user created command file which when compiled creates a binary executable command. the command is created in the “commands/simple” directory”. The file once compiled creates an executable binary in the “commands/simple/bin” directory.You will need to do a sunread to get the bin from the solaris system to the minix system

System Call

All the headers used in the system calls are kept in the "include" directory. The "type.h " header file is a very important and most useful header file. To pass a message a variable of a specific data type is defined, and the variable is added to the message structure

System Call

Typedef struct { datatype mnYY; } mess_n;n => message number of the messageYY => variable nameThe size of the structure defined in the message is also an important factor as if the size of the message is increased then the system crashes

System Call

Typedef struct { char *m1sb; } mess_1;#define m1_sb m_u.m_m1.m1sb; To add data in the message variable the following need to be doneMessage m;m.m1_sb = data

What is MINIX 3

MINIX 3 is a new open-source operating system designed to be highly reliable, flexible, and secure. It is loosely based somewhat on previous versions of MINIX, but is fundamentally different in many key ways. MINIX 1 and 2 were intended as teaching tools;MINIX 3 adds the new goal of being usable as a serious system on resource-limited and embedded computers and for applications requiring high reliabilityThis new OS is extremely small, with the part that runs in kernel mode under 6000 lines of executable code. The parts that run in user mode are divided into small modules, well insulated from one another. For example, each device driver runs as a separate user-mode process so a bug in a driver (by far the biggest source of bugs in any operating system), cannot bring down the entire OS.

In fact, most of the time when a driver crashes it is automatically replaced without requiring any user intervention, without requiring rebooting, and without affecting running programs. These features, the tiny amount of kernel code, and other aspects greatly enhance system reliability.MINIX 3 is initially targeted at the following areas:

Applications where very high reliability is requiredSingle-chip, small-RAM, low-power, $100 laptops for Third-World childrenEmbedded systems (e.g., cameras, DVD recorders, cell phones)Applications where the GPL is too restrictive (MINIX 3 uses a BSD-type license)Education (e.g., operating systems courses at universities)

MINIX 3 Features

POSIX compliantNetworking with TCP/IPX WindowSystemLanguages: cc, gcc, g++, perl, python, etc.Over 650 UNIX programsMany improvements since V2Full multiuser and multiprogrammingDevice drivers run as user processesHigh degree of fault toleranceFull C source code supplied

Hardware Required

To run MINIX 3, need a PC driven by a Pentium CPU or compatible. The standard configuration requires 16 MB of RAM. An 8-MB version is also available, but it is slower due to a smaller buffer cache. Since the distribution comes on a live CD, can be tested it without allocating any hard disk space, but for a hard disk installation, 50 MB is needed as a minimum, 600 MB minimum if you want all the sources.

User ViewFrom the user's point of view, MINIX 3 looks like UNIX, except less bloated. It comes with the X Window System and over 400 standard UNIX programs, including:

Shells: ash, bash, pdksh, rshEditors: emacs, nvi, vim, elvis, elle, mined, sed, ed, exLanguage tools: cc, gcc, g++, bison, flex, perl, python, yaccProgramming tools: cdiff, make, patch, tar, touchNetworking: ssh, telnet, ftp, lynx, mail, rlogin, wget, pineFile utilities: cat, cp, bzip2, compress, mv, dd, uue, GNU utilitiesText utilities: grep, head, paste, prep, sort, spell, tailAdministration: adduser, cron, fdisk, mknod, mount, cvs, rcsGames: dungeon, nethack

Currently the user interface is just X, but someday a GUI may beadded if a suitable lightweight GUI can be found.

AvailabilityMINIX 3 is open source software, under the BSD license. It has its own http://www.minix.org from which the a bootable CD-ROM image containing all the sources and binaries can be downloaded. To install it, just boot the CD-ROM, login as root, and type: setup. Installation takes about 10 minutes. After installation, a large number of packages can be installed from the CD-ROM or the Website by just typing: packman to select the choices.Currently MINIX 3 runs on x86 hardware, but ports to the PowerPC and Xscale are underway. It also runs fine on virtual machines such as VMware and Xen.

Since MINIX 3 went public in late 2005, the Website has had over 300,000 unique visitors and the CD-ROM image has been downloaded some 75,000 times. Currently, the site is getting over 1000 visitors a day. There is an active Google USENET newsgroup, comp.os.minix, where people ask and answer questions, post new software, and discuss MINIX 3. MINIX 3 is a community effort and your help is most welcome. Go get the system, try it out, and join the future.

What programming languages and compilers are supported by Minix?he Minix operating system itself and the various utilities and programs that are part of the Minix distribution are written in C, and the distribution includes a C compiler. In fact, Minix also provides compilers for Pascal and Modula2;Other C compilers:

C386Gcc is the standard Minix-vmd compiler. The TenDRA C/C++ Compiler has been ported to Minix by Jose Juan Mendoza Rodriguez.

Compilers and interpreters for other languages

BASIC: The Brandy BASIC language interpreter, version 1.0.16, has been ported to Minix by HaraldArnesen <harald@skogtun.org>. FORTRAN: A FORTRAN to C converter has been ported to Minix and is available on this system. Perl: A port of Perl 5 is available on this system. Python: new 1/2005: Python version 1.5.2 (not the latest version, but less resource hungry than the latest version) has been ported to Minix by Michael Kennett. RATFOR: This is the "RATional FORtran" preprocessor for FORTRAN described in the original Software Tools book by Brian Kernighan and P. J. Plauger.

Exchanging Data with Other Operating Systems

ftp(1)rcp(1) . kermit(9) to transfer data via modem or over a serial line connection.Exchange of data between different operating systems running at different times on the same computer (or at the same time using a virtual or emulated machine such as provided by VMWare and Bochs)With floppy disks the only problem is to interpret the data structures used by the foreign file system. With hard disk partitions there may be another problem to be solved first: although all operating systems that use the same hardware platform must use the method of defining primary disk partitions that is supported by the system's ROM boot code, operating system designers have devised various ways of further dividing primary partitions into subpartitions.

File Transfers between Guest and Host OS on Virtual or Emulated Systems

With a virtual or emulated host platform, as provided by Bochs or VMWare, one frequently needs to transfer data from the host OS to the guest OS or vice versa. Depending on the capabilities of the two systems, there may be several ways to do this.Network connection: If both the host and the guest are network-capable, then file transfers are easy. With MINIX on Bochs on a Windows host the host can use ftp to get and put files into the file space of the MINIX guest. If a direct network connection between the guest and the host isn't possible, transfer of files through the file space of another machine on the network might be the easiest way.

Floppy disks: If the guest OS can write to physical floppy disks, these can be used to transfer files.MINIX can usemtools or the dosread and doswrite programs to access an MS-DOS formatted floppy disk.From the Windows host sidemintools can be used to access MINIX disks. For files too big to fit on a floppy disk the fdvol utility provided in the dosutils directory on MINIX download sites can be used on the Windows host side to write to multiple disks that the MINIX guest can read with the vol command. From the MINIX side dd can be used to break a large file into smaller chunks that doswrite or mtools can write to MS-DOS floppy disks, and on the Windows side the MS-DOS copy command can be used to concatenate smaller files to a larger file.

Virtual disks: With Bochs on Windows 98 access to physical floppy disks from a guest OS is not supported, so only files used as virtual disks can be read and written by the guest OS. But in many cases virtual disks are easier to use than physical floppy disks anyway, especially since access to floppy disks from Bochs is very slow. Fortunately, unlike a virtual hard disk, new virtual floppy disks can be created while running Bochs, and multiple virtual floppy disks can be accessed during a single session. Also, mtools can be used to format a virtual floppy disk with an MS-DOS FAT file system, and on the Windows side there is a free program, DiskExplorer, that can transfer files back and forth between the virtual disk and the Windows host file system.

Some screenshots