Skip to content

Latest commit

 

History

History
238 lines (176 loc) · 9.5 KB

Nachos.md

File metadata and controls

238 lines (176 loc) · 9.5 KB
Raw

NachOS

Not Another Completely Heuristic Operating System, or Nachos, is instructional software for teaching undergraduate, and potentially graduate level operating systems courses. It was developed at the University of California, Berkeley, designed by Thomas Anderson, and is used by numerous schools around the world.

Dependency Graph

In Makefile.common

# The dependency graph between assignments is:
#   1. THREADS before everything else
#   2. USERPROG must come before VM
#   3. USERPROG can come before or after FILESYS, but if USERPROG comes
#      before (as in this distribution), then it must define FILESYS_STUB
#
#   Other than that, you have complete flexibility.

Directory Structure

Makefiles

  • Makefile
  • Makefile.common
  • Makefile.dep

Folder

  • bin: for MIPS interpreter (coff2noff)
  • machine: for MIPS environment simulation
  • threads: main and threads
  • userprog: user program, system call and exception
  • test: some user program test
  • filesys: file system
  • network
  • vm

Executables

  • nachos: one for each compile (subdirectory "machines" which with different define/macro settings)
  • coff2noff: converting a COFF (Common Object File Format) file to a NOFF file (Nachos Object File Format)

coff2noff

For more detail checkout here

Nachos runs user programs in their own private address space. Nachos can run any MIPS binary.

In Unix, "a.out" files are stored in "coff" format. Nachos requires that executables be in the simpler "Noff" format.

Use the coff2noff program to convert binary. Consult the code/test/Makefile for details.

When executing a program, Nachos

  1. creates an address space
  2. copies the contents of the instruction
  3. initialized variable segments into the address space
  4. (the uninitialized variable section doesn't need to be read from the file, since it is defined to contain all zeros)

Noff

Noff-format files consist of four parts

  1. Noff header
    • describes the contents of the rest of the file
    • giving information about the program's instruction, initialized variables and uninitialized variables

Noff header resides at the very start of the file. And containes pointers to the remaining section.

  • noffMagic: a reserved "magic" number that indicates that the file is in Noff format. (first 4 bytes of the file)
  • virtualAddr: what virtual address that segment begins at (normally zero)
  • inFileAddr: pointer within the Noff file where that section actuall begins (so that Nachos can read it into memory before execution begins)
  • size:the size (in bytes of that segment)

Debugging Nachos

Internal Debugging in Nachos

The Trace Facility

The -d argument

nachos -d <debug_flag>

code/lib/debug.h (does not exist in current version Nachos code, but the flags are the same)

// The pre-defined debugging flags are:

const char dbgAll = '+';		// turn on all debug messages
const char dbgThread = 't';		// threads
const char dbgSynch = 's';		// locks, semaphores, condition vars
const char dbgInt = 'i'; 		// interrupt emulation
const char dbgMach = 'm'; 		// machine emulation (USER_PROGRAM)
const char dbgDisk = 'd'; 		// disk emulation (FILESYS)
const char dbgFile = 'f'; 		// file system (FILESYS)
const char dbgAddr = 'a'; 		// address spaces (USER_PROGRAM)
const char dbgNet = 'n'; 		// network emulation (NETWORK)

The debug flag is defined in code/threads/utility.h

//	The debugging routines allow the user to turn on selected
//	debugging messages, controllable from the command line arguments
//	passed to Nachos (-d).  You are encouraged to add your own
//	debugging flags.  The pre-defined debugging flags are:
//
//	'+' -- turn on all debug messages
//   	't' -- thread system
//   	's' -- semaphores, locks, and conditions
//   	'i' -- interrupt emulation
//   	'm' -- machine emulation (USER_PROGRAM)
//   	'd' -- disk emulation (FILESYS)
//   	'f' -- file system (FILESYS)
//   	'a' -- address spaces (USER_PROGRAM)
//   	'n' -- network emulation (NETWORK)

...

extern void DEBUG (char flag, char* format, ...);  	// Print debug message 
							// if flag is enabled

I've add c for (random) Context Switch used in threads/system.cc. I've add b for Barrier related in threads/synch.cc I've add w for Reader-Writer Lock related in threads/synch.cc I've add T for TLB handling in machine/exception.cc I've add M for memory management (allocation, data structure (e.g. bitmap)) in machine/machine.cc I've add S for system call in machine/exception.cc I've add D for multi-level directory in filesys/filesys.cc

Single Stepping

The -s argument

Assertions

ASSERT()

External Debugger

Using GDB with Nachos

gdb nachos

Links

UC Berkeley

Developed originally at U.C., Berkeley.

University of Waterloo

C++

JAVA

CSC546 - Operating Systems

Goal

  • Implement system calls for Read, Write, Exit, Join, Exec, etc.
  • Implement vitual memory so that multiple programs can be in memory at the same time.
  • Implement paging so that Mips physical memory limitations don't limit the number or size of the Mips user programs that can execute concurrently.

Duke University

  • CPS 110 / EE 153 Operating Systems - Y2K spring
    • Nachos Project Guide
      • Nachos Lab Assignments
        • Lab 1: The Trouble with Concurrent Programming
        • Lab 2: Threads and Synchronization
        • Lab 3: Programming with Threads
        • Lab 4: Multiprogrammed Kernel
        • Lab 5: I/O
        • Lab 6: Virtual Memory

Longwood University