1. The Nachos Instructional OS and CS170 Projects
Tao Yang
11/15/2018
The Nachos Instructional OS and CS170 Projects
CS 170, Tao Yang, Fall 2010
Thank you for the introduction. In this presentation, I plan to talk about my research on cluster-based network services. My work has been focusing on three specific aspects: service replication, load-balancing support, and a QoS-aware resource management framework. This study was supervised by my advisor, Tao Yang, at UC Santa Barbara.

2. What is Nachos OS?
Allow students to examine, modify and execute operating system software.
A skeletal OS that supports threads and user-level processes, and simulates the general low-level facilities of typical machines, including interrupts, virtual memory and interrupt-driven device I/O.
Difference between Nachos and a hosting OS: Nachos is an OS running on a virtual machine, executed as a single Unix process in a hosting OS.
whereas a real OS runs on bare machines.
Over 9K lines of C++ code.
Good news: Can understand its basic mechanisms by reading about 1-2K lines of code.
11/15/2018

3. System Layers Nachos Thread 1 Thread 2 Thread N Nachos Kernel
(Threads, File System, Code execution/memory mapping,
System calls/Interrupt)
Simulated MIPS Machine
(CPU, Memory, Disk, Console)
Base Operating System (Linux for our class)

4. Nachos code directory
machine --- Basic machine specification (MIPS simulator).
threads --- threads management (Project 1).
userprog -- binary code execution and system calls (Project 2).
vm -- virtual memory (empty, Project 3).
filesys -- file system (used in Projects 2/3)
test -- binary test code (short user test programs, Projects 2/3).
network -- networking protocol (not used in our projects).
bin -- utilities/tools (binary format conversion)
11/15/2018

5. Project 0 (Oct 6) Obtain and install Nachos source code.
Copy the source code from ~cs170/nachosSept20.tar.gz
Compile the source code using gmake and Check if it works
Run threads demo under the threads subdirectory (just run kernel test threads).
Run user program demo under the userprog subdirectory.
Submit the code to exercise code submission process. Also tell us your group.
11/15/2018

6. Nachos Threads
Nachos threads execute and share the same code, share the same global variables.
The Nachos scheduler maintains a ready list, containing all threads that are ready to execute.
Each thread is in one of four states: READY, RUNNING, BLOCKED, JUST_CREATED.
Each thread object maintains a context block.
Thread object supports the following operations:
Thread(char *debugName). Create a thread.
Fork(VoidFunctionPtr func, int arg). Let a thread execute a function.
Yield(). Suspend the calling thread and select a new one for execution.
Sleep(). Suspend the current thread, change its state to BLOCKED, and remove it from the ready list
Finish()
11/15/2018

7. Sample Example of Nacho Threads
main () {
Thread *t1 = new Thread("forked thread1");
Thread *t2 = new Thread("forked thread2");
t1->Fork(SimpleThread, 1);
t2->Fork(SimpleThread, 2);
SimpleThread(3); }
SimpleThread(int i)
printf(“Hello %d\n”, i);
currentThread->Yield();
Create 2 new threads.
Start to fork and execute a function in each child thread.
Parent also executes the same function
Function executed by threads

8. Nachos Thread States and Transitions
running
(user)
When running in user mode, the thread executes within the machine simulator. Proj 2 covers this.
In Proj 1 we are only concerned with the states in this box.
Machine::Run,
ExceptionHandler
interrupt or
exception
running
(kernel)
Thread::Yield
Thread::Sleep
Scheduler::Run
blocked
ready
Scheduler::ReadyToRun

9. Thread Switching
Switching involves suspending the current thread, saving its state, and then restoring the state of the new thread.
Following code involved in execution: the old code, the new code, and the code that performs switching.
Switch(oldThread, newThread):
Save all registers in oldThread's context block.
Save the program address to be used when the old thread is resumed.
Load new values into the registers from the context block of the new thread.
Once the saved PC of the new thread is loaded, Switch() is no longer executing.
11/15/2018

10. Scheduler object for thread scheduling
A scheduler decides which thread to run next by scanning the ready list.
The scheduler is invoked whenever the current thread gives up the CPU.
The current Nachos scheduling policy is round-robin: new threads are appended to the end of the ready list, and the scheduler selects the front of the list.
The Scheduler object has the following operations:
ReadyToRun(Thread *thread).
Make thread ready to run and place it on the ready list.
Thread *FindNextToRun()
Run(Thread *nextThread)
11/15/2018

11. Semaphore object for thread synchronization
Disable and re-enable interrupts to achieve mutual exclusion (e.g., by calling Interrupt::SetLevel()).
Operations for a Semaphore object:
Semaphore(char* debugName, int initialValue)
P(): Decrement the semaphore's count, blocking the caller if the count is zero.
V() :Increment the semaphore's count, releasing one thread if any are blocked waiting on the count.
11/15/2018

12. Key steps when Nachos executes
After you type ``nachos'' under threads subdirectory:
It is executing as a single Unix process.
The main() calls
Initialize() to start up interrupt handling, create a scheduler for managing the ready queue.
ThreadTest() (to be explained for Project 1).
currentThread->Finish() to let other threads continue to run.
11/15/2018

13. Key Calling graph when Nachos executes under thread directory
All files are in threads directory.
StackAllocate()
in thread.cc
Thread:Fork ()
in thread.cc
Initialize()
in system.cc
FindNextToRun ()
in scheduler.cc
SWITCH ()
in switch.s
main() in
main.cc
Thread:Yield ()
in thread.cc
ReadyToRun ()
in scheduler.cc
ThreadRoot ()
in switch.s
ThreadTest ()
in threadtest.cc
func() such as
SimpleThread()
in ThreadTest.cc
Run ()
in scheduler.cc
currentThread->Finish ()
in threadtest.cc
11/15/2018

14. Project 1: threads & synchronization
Work under threads subdirectory.
Modify ThreadTest() to do simple threads programming (spawning multiple threads).
Implement locks and condition variables (missing from the file synch.cc).
Design am application using the implemented synchronization primitives.
Workload:
Read Nachos code and add few hundred lines of code.
Implemented synchronization primitives will be used in Projects 2 and 3.
11/15/2018

15. Project 1: Files involved
Key files
main.cc, threadtest.cc -- a simple test of our thread routines.
thread.h thread.cc -- Nachos thread data structure and operations.
scheduler.h scheduler.cc The thread ready list.
synch.h synch.cc -- synchronization routines.
Other related files.
synchlist.h, synchlist.cc -- synchronized access to lists using locks/conditions (useful examples for your programming).
list.h list.cc -- generic list management.
system.h, system.cc -- Nachos startup/shutdown routines.
utility.h utility.cc -- some useful definitions and debugging routines.
interrupt.h interrupt.cc -- manage interrupts.
time.h timer.cc -- clock emulation.
switch.h, switch.s -- assembly code for thread switching.
stats.h stats.cc -- collect interesting statistics.
11/15/2018

16. Machine Source code: under machine subdirectory.
Roughly approximates the MIPS architecture
Machine has registers, memory, a CPU and a clock.
Simulated clock used for event scheduling and execution (interrupts).
Can execute an arbitrary program with a sequence of MIPS instructions:
11/15/2018

17. Machine: Code execution Steps
Load instructions into the machine's memory.
Initialize registers (including the program counter PCReg).
Tell the machine to start executing instructions.
The machine then fetches the instruction PCReg points at, decodes it, and executes it.
The process is repeated until an illegal operation is performed or an interrupt is generated.
When a trap or interrupt takes place, an interrupt service routine deals with the condition.
11/15/2018

18. Two modes of executions
User mode (executing MIPS instructions of a user program)
Example: Halt code in test directory
Nachos executes user-level processes by loading them into the simulator's memory, initializing the simulator's registers and then running the simulator.
User-programs can only access the memory associated with the simulated machine.
11/15/2018

19. Two modes of executions
Kernel mode
kernel executes when Nachos first starts up and loads a user program.
or when a user-program executes an instruction that causes a ``hardware’’ trap
illegal instruction,
page fault (access memory address which does not exist)
system call
11/15/2018

20. Machine Object: Implement a MIPS machine
an instance created when Nachos starts up.
Supported public variables:
Registers: 40 registers.
Memory: Byte-addressable.
Virtual memory: use a single linear page table or a software-managed TLB.
11/15/2018

21. Machine Object: Supported operations
Machine(bool debug).
Translate(int virtAddr, int* physAddr, int size, bool writing).
OneInstruction().
Run()
ReadRegister(int num)
WriteRegister(int num, int value)
ReadMem(int addr, int size, int* value)
WriteMem(int addr, int size, int value)
11/15/2018

22. Machine Object: Supported operations
Machine(bool debug).
Translate(int virtAddr, int* physAddr, int size, bool writing).
OneInstruction().
Run()
ReadRegister(int num)
WriteRegister(int num, int value)
ReadMem(int addr, int size, int* value)
WriteMem(int addr, int size, int value)
11/15/2018

23. Interrupt Object
Maintain an event queue together with a simulated clock.
Supported operations:
Schedule(VoidFunctionPtr handler, int arg, int when, IntType type) Schedule a future event to take place at time ``when''.
Usage: schedule a yield at random interval.
SetLevel(IntStatus level). Used to temporarily disable and re-enable interrupts for mutual exclusion purposes. Two levels are supported: IntOn and IntOff.
OneTick()--
CheckIfDue(bool advanceClock). Examines if some event should be serviced.
Idle(). ``advances'' to the clock to the time of the next scheduled event
11/15/2018

24. Interrupt::OneTick()
Software managed clock.
The clock advances 1 tick for user mode, 10 for system mode
after every restored interrupt (disable/enable Interrupt)
or after the MIPS simulator executes one instruction.
When the ready list is empty, fast-advance ticks until the next scheduled event happens.
11/15/2018

25. Timer object Generate interrupts at regular or random intervals
Then Nachos invokes the predefined clock event handling procedure.
Supported operation:
Timer(VoidFunctionPtr timerHandler, int callArg, bool doRandom).
Create a real-time clock that interrupts
every TimerTicks (100) time units
Or set this a random number for random mode
11/15/2018

26. Console Object
Simulates the behavior of a character-oriented CRT device
Data can be written to the device one character at a time through the PutChar() routine.
Input characters arrive one-at-a-time. They can be retrieved by GetChar().
Supported operations:
Console(char *readFile, char *writeFile, VoidFunctionPtr readAvail,VoidFunctionPtr writeDone, int callArg).
Create a console instance.``readFile'' is the Unix file of where the data is to be read from; if NULL, standard input is assumed.
PutChar(char ch)
GetChar()
11/15/2018

27. Disk Object Simulates the behavior of a real disk.
The disk has only a single platter, with multiple tracks (32).
Each track contains the same number of sectors (32).
Allow only one pending operation at a time.
Contain a ``track buffer'' cache. Immediately after seeking to a new track, the disk starts reading sectors, placing them in the track buffer.
Supported operations:
Disk(char *name, VoidFunctionPtr callWhenDone, int callArg)
ReadRequest(int sectorNumber, char *data)
WriteRequest(int sectorNumber, char *data)
ComputeLatency(int newSector, bool writing)
11/15/2018

28. Executing a user program
halt
shell
user space
MIPS instructions executed
by the emulator
data
ExceptionHandler()
Nachos kernel
MIPS emulator
Machine::Run()
fetch/execute
examine/deposit
SaveState/RestoreState
examine/deposit Rn
page table
process page tables
Machine
object SP PC
registers
memory

29. From C program to MIPS binary
myprogram.c
myprogram.o
object file
int j;
char* s = “hello\n”;
int p() {
j = write(1, s, 6);
return(j); }
data
assembler
data
data
data
libraries and other objects
….. p:
store this
store that
push
jsr _write
ret
etc.
linker
Executable images are also built from separately developed components (modules)...
separate compilation
symbol tables
...linked together by system utilities.
cross-module procedure calls and data references
relocation records and linkage sections
static link-and-load in “traditional” Unix
DLLs and shared libraries
importance of calling conventions
gcc
compiler
data
program
myprogram.s
myprogram
(executable file)

30. What’s in an Object File?
Header “magic number”
indicates type of image.
text
data
idata
wdata
header
symbol
table
relocation
records
program instructions p
Section table an array
of (offset, len, startVA)
immutable data (constants)
“hello\n”
program sections
writable global/static data
j, s
Used by linker; may be removed after final link step and strip.
j, s ,p,sbuf
int j = 327;
char* s = “hello\n”;
char sbuf[512];
int p() {
int k = 0;
j = write(1, s, 6);
return(j); }

31. Binary code format (Noff)
Source code: under userprog subdirectory.
The current Nachos can run a single MIPS binary (Noff format) e.g. type ``nachos -x ../test/halt''.
A user program must be compiled using a cross-platform gcc compiler that generates MIPS code.
A Noff-format file contains (bin/noff.h)
the Noff header, describes the contents of the rest of the file
executable code segment (TEXT)
initialized data segment (DATA)
uninitialized data segment (BSS).
11/15/2018

32. Space usage during execution of a C program
STACK
HEAP
BSS
DATA
TEXT
Stack grows from top-down.
Heap grows bottom-up
Uninitialized data
Initialized data
Code

33. TEXT, DATA, BSS, HEAP, STACK in C
Tao Yang
11/15/2018
TEXT, DATA, BSS, HEAP, STACK in C
Int f3=3; /* DATA segment */
Int f1; /*BSS segment*/
def[] = "1"; /* DATA segment */
int main(void) { static char abc[12], /* BSS segment */ static float pi = ; /* DATA segment */ int i = 3; /* Stack*/
char *cp; /*stack*/
cp= malloc(10); /*malloc allocates space from HEAP*/
f1= i+f3; /* code is in TEXT*/
strcpy(abc , "Test" ); /* “Test” is located in DATA segment */ }
11/15/2018

34. Noff format virtualAddr: virtual address that segment begins at.
. Each segment has the following information:
virtualAddr: virtual address that segment begins at.
inFileAddr: Pointer within the Noff file where that section actually begins.
The size (in bytes) of that segment.
11/15/2018

35. User process for executing a program
A Nachos thread is extended as a process
Each process has its own address space containing
Executable code (Code segment)
Initialized data (Data segment)
Uninitialized data (BSS)
Stack space for function calls/local variables
how big is address space?
A process owns some other objects, such as open file descriptors.
11/15/2018

36. Steps in User process creation
Tao Yang
11/15/2018
Steps in User process creation
Currently only execute a single user program.
Create an address space.
Zero out all of physical memory (machine->mainMemory)
Read the binary into physical memory and initialize data segment.
Initialize the translation tables to do a one-to-one mapping between virtual and physical addresses.
Zero all registers, setting PCReg and NextPCReg to 0 and 4 respectively.
Set the stackpointer to the largest virtual address of the process (stack grows downward).
11/15/2018

37. Key Calling graph when Nachos executes under userprog directory
Executable file
ReadAt()
Space=
New AddrSpace()
in addrspace.cc
Initialize()
in system.cc
Machine->
WriteRegister()
Space->
InitRegisters()
main() in
main.cc
StartProcess ()
in progtest.cc
Space
->RestoreState()
Machine->
OneInstruction()
Machine->Run ()
in mipssim.cc
Interupt->
OneTick()
In Interupt.cc
11/15/2018

38. Creating a Nachos Process (userprog/progtest.cc)
void StartProcess(char *filename) {
OpenFile *executable;
AddrSpace *space;
executable = fileSystem->Open(filename);
if (executable == NULL) {
printf("Unable to open file %s\n", filename);
return; }
space = new AddrSpace(executable);
currentThread->space = space;
delete executable; // close file
space->InitRegisters();
space->RestoreState();
machine->Run();
ASSERT(FALSE);
Create a handle for reading text and initial data out of the executable file.
Create an AddrSpace object, allocating physical
memory and setting up the process page table.
Set address space of current thread/process.
Initialize registers, load pagetable, and begin execution in user
mode.

39. Creating a Nachos Address Space (userprog/addrspace.cc)
AddrSpace::AddrSpace(OpenFile *executable) {
NoffHeader noffH;
unsigned int i, size;
executable->ReadAt((char *)&noffH, sizeof(noffH), 0);
// how big is address space?
size = noffH.code.size + noffH.initData.size + noffH.uninitData.size
+ UserStackSize; // we need to increase the size to leave room for the stack
numPages = divRoundUp(size, PageSize);
size = numPages * PageSize;
pageTable = new TranslationEntry[numPages];
for (i = 0; i < numPages; i++) {
pageTable[i].virtualPage = i; // for now, virtual page # = phys page #
pageTable[i].physicalPage = i;
pageTable[i].valid = TRUE; }
....
Read the header of binary file
Compute address space need
Setup a page table for address translation

40. Initializing a Nachos Address Space
Zero out memory allocated
bzero(machine->mainMemory, size);
// copy in the code and data segments into memory
if (noffH.code.size > 0) {
noffH.code.virtualAddr, noffH.code.size);
executable->ReadAt(&(machine->mainMemory[noffH.code.virtualAddr]),
noffH.code.size, noffH.code.inFileAddr); }
if (noffH.initData.size > 0) {
noffH.initData.virtualAddr, noffH.initData.size);
executable->ReadAt(&(machine->mainMemory[noffH.initData.virtualAddr]),
noffH.initData.size, noffH.initData.inFileAddr);
Copy code segment to memory
Copy initialized data segment to memory

41. System Calls & Exception Handling
User programs invoke system calls by executing the MIPS ``syscall'' instruction
``syscall'' generates a hardware trap into the Nachos kernel.
A trap is implemented by invoking RaiseException() with arguments indicating the trap cause.
RaiseException() calls ExceptionHandler() to take care of the
specific problem.
The system call number is stored in Register 2 and the return address is in Register 31.
Assembly code for Halt():
Halt:
addiu $2,$0,SC_Halt
syscall
j $31
.end Halt
11/15/2018

42. When typing “nachos –x halt”
The main thread starts by running function StartProcess() in file progtest.cc. This thread is used to run halt binary.
StartProcess() allocates a new address space and loads the halt binary. It also initializes registers and sets up the page table.
Call Machine::Run() to execute the halt binary using the MPIS emulator.
The halt binary invokes the system call Halt(), which causes a trap back to the Nachos kernel via functions RaiseException() and ExceptionHandler().
The exception handler determines that a Halt() system call was requested from user mode, and it halts Nachos.
11/15/2018

43. Nachos –x halt using halt.c in test directory
Machine->
RaiseException(SyscallException)
Machine->
OneInstruction()
Machine->Run ()
in mipssim.cc
ExceptionHandler(SyscallException)
Interrupt->
Halt()
In Interupt.cc
11/15/2018

44. Proj 2: Multiprogramming&System Calls
Modify source code under userprog subdirectory.
~1200 lines of code.
The crossplatform compiler is under ~cs170/gcc.
This compiler on x86 machines produces a.out with the coff format.
Use utility coff2noff (under nachos’ bin directory) to convert it as Noff.
Check the makefile under test subdirectory on how to use gcc and coff2noff.
System calls to be implemented:
Multiprogramming: Fork(), Yield(), Exit(), Exec() and Join().
File and console I/O: Creat(), Open(), Read(), Write(), and Close().
11/15/2018

45. Multi-Processes and the Kernel
text
data
BSS
user stack
args/env
kernel area
text
data
BSS
user stack
args/env
kernel area
text
data
BSS
user stack
args/env
kernel area
2n-1
2n-1
Nachos kernel
2n-1

46. To run multiple processes in Proj 2
Tao Yang
11/15/2018
To run multiple processes in Proj 2
Nachos should
Provide the physical memory management;
Set up a address translation table with linear page tables;
Save/restore address-space related state during process switching (AddrSpace::SaveUserState() and AddrSpace:RestoreUserState() are called).
11/15/2018

47. Address translation with linear page tables
A virtual address is split into page number and page offset components
Machine->pageTable points to the page table to be used.
Machine->pageTableSize -- the actual size of the page table.
Process switching requires to set the above pointer properly for each user.
Physical page 0 starts at machine-> mainMemory.
Each page has 128-bytes. The actual number of physical pages is NumPhysPages (32).
11/15/2018

48. A Simple Page Table
Each process/VAS has its own page table. Virtual addresses are translated relative to the current page table.
process page table
PFN 0
PFN 1
PFN i
In this example, each VPN j maps to PFN j, but in practice any physical frame may be used for any virtual page.
PFN i +
offset
page #i
offset
user virtual address
The page tables are themselves stored in memory; a protected register holds a pointer to the current page table.
physical memory
page frames

49. Project 2: Files involved
Key files.
progtest.cc -- test routines to run user code.
addrspace.h addrspace.cc -- create an address space and load the program from disk.
syscall.h -- the system call interface.
exception.cc -- the handler for system calls and other user-level exceptions such as page faults.
filesys.h, openfile.h console.h -- interface to the Nachos file system and console.
Other related files:
bitmap.h bitmap.cc -- manipulate bitmpas (useful for keeping track of physical page frames).
translate.h, translate.cc -- translation tables.
machine.h, machine.cc -- emulates main memory, processor, etc.
mipsim.cc -- emulates MPIS R2/3000 instructions.
console.cc -- emulates a terminal using UNIX files.
11/15/2018

50. Nachos File System Two versions (check openfile.h and filesys.h):
A ``stub'' version is simply a front-end to the Unix filesystem for project 2 and part 1 of project 3.
Implemented on top of a raw disk. Will be extended in part 2 of Project 3
Function layers (from top to down):
FileSystem object
Created by fileSystem = new FileSystem(format) in system.cc
OpenFile objects (many)
Created by every call to open/access a file in a directory.
SynchDisk object
Created by synchDisk = new SynchDisk("DISK") in system.cc
The Disk object.
Created by disk = new Disk(name,..) in SynchDisk::SynchDisk()
11/15/2018

51. File System Layers in Nachos
FreeMap Bitmap for
32x32 blocks
Directory: Manage
a directory of file names
Nachos kernel thead
FileSystem:
Directory management file create/open/delete
FileHeader: i-node
OpenFile: access individual file with read/write/seek.
Operate on bytes.
SynchDisk: synchronous access to a disk with concurrent threads.
Operate on sectors.
Disk: low-level interface that initiates
asynchronous IO to physical disk sectors
Base Operating System (Linux for our class)

52. Operations of File System Object
FileSystem(bool format).
called once at ``boot'' time.
For the stub version, just use Unix file system
Otherwise create a directory/control info.
Sector 0 is fileheader (i-node) for FreeMap. Sector 1 is i-node for directory table.
Create(char *name, int initialSize).
Create a Nachos disk file. ``initialSize'' is ignored in the stub version; Unix doesn't require it.
OpenFile *Open(char *name).
Assume both read and write access.
in the stub version, Open simply opens the Unix file.
Remove(char *name)
List()
11/15/2018

53. Directory Table stored in DirectoryFile
Sector 1 is the i-node (file header).
File content is 10 table entries.
DirectoryFile disk space is allocated in FileSystem() during initialization …
Bool inUse --- is this entry used?
Int sector --- location of file header (i-node)
Filename characters+ 1 for ‘\n’ …
11/15/2018

54. directory.cc Limit Directory Object attributes Operations
FileNameMaxLen 9 // 9 characters at most for a file name
NumDirEntries // at most 10 files
Directory Object attributes
tableSize -- # of directory entries which is 10 now.
table = in-memory directory entries, each of which is for one Nachos file. Content is copied from and copies back to a disk DirectoryFile.
Operations
Directory (int size) -- Create an in-memory directory of the desired size.
FetchFrom (OpenFile *file) -- Fetch disk DirectoryFile that contains directory entries, and copy to in-memory directory table.
WriteBack(OpenFile *file) -- Write back in-memory directory content to disk DirectoryFile
called every time when a file is added or removed to directory.
FindIndex (Char *name) --Search a file string name in a directory
Add (Char *name, int sector) – Add file name into a directory with disk sector no that contains the file header (i-node).
Remove(char *name) – remove a file.
11/15/2018

55. File header (i-node) …
int numBytes; // file size
One filer header per file, fitting one sector (128 bytes)
Operations
Allocate(BitMap *bitMap, int fileSize); Initialize a file header
FetchFrom (int SectorNo) -- Fetch Fileheader sector from disk.
WriteBack(int SectorNo) -- Write back in-memory file header content to disk
ByteToSector(int offset) –Convert a file offset in bytes to a sector no
int numSectors; //sectors used
Data
sector
int dataSectors[NumDirect]
Data sector pointer 0
Data
sector
Data sector pointer 1 …
Data
sector
Data sector pointer 29
11/15/2018

56. OpenFile Object OpenFile(int sector)
sector – the location on disk of the file header.
Create an OpenFile object which contains file control info, loaded from the disk file header.
Seek(int position)
Read/write in the current position
Read(char *buffer, int numBytes)
Write(char *buffer, int numBytes)
Read/write in a specific position
ReadAt(char *buffer, int numBytes, int FilePosition).
Identify specific sectors in the file and fetch them, copy to buffer.
WriteAt(char *buffer, int numBytes, int FilePosition)
May read first/last sectors, and then write out updated sectors.
Length(). Return the file size.
11/15/2018

57. SynchDisk Object: Synchronously access a disk
Called only once to create a physical disk object. Set the disk interrput hander as RequstDone().
Create lock/semaphore for synchronization.
Notice that physical disk is an asynchronous device (disk requests return immediately, and an interrupt happens later on).
ReadSector(int sectorNumber, char* buffer)
Send a read request for a sector
Wait IO complete (wait for interrupt using a semaphone)
WriteSector(int sectorNumber, char* data)
Send a sector write request. Wait for interrupt.
RequestDone()
Disk interrupt handler. Wake up any thread waiting for the disk request to finish.
11/15/2018

58. Disk Object Simulates the behavior of a disk I/O device.
The disk has only a single platter, with multiple tracks (32).
Each track contains the same number of sectors (32).
Each sector is 128 bytes
Disk size = 32x32*128 =128K
Asynchronous read/write with an option of disk cache
Supported operations:
Disk(char *name, VoidFunctionPtr callWhenDone, int callArg)
Create a disk: just create a Unix file to simulate.
Setup a handling function (RequestDone in SynchDisk.cc) when a read/write request is done.
11/15/2018

59. Operations in Disk device
ReadRequest(int sectorNumber, char *buffer)
Read from the specific location of the “physical disk”.
ticks = ComputeLatency(sectorNumber, FALSE);
interrupt->Schedule(DiskDone, (int) this, ticks, DiskInt);
WriteRequest(int sectorNumber, char *data)
Write data to specific location of the “physical disk”.
ticks = ComputeLatency(sectorNumber, TRUE);
ComputeLatency(int newSector, bool writing)
Latency= seek time + rotation time
11/15/2018

60. Project 3 Workload vm directory for part 1 is empty
Need to come up the design and code
Leverage Project 2 experience
Test C programs provided are sample code and they may contain bugs.
Amount of work
Part 1. ~400 lines of code in vm ( few in userprog)
Part 2. ~250 or less in filesys (few in userprog)
Part 1 and 2 can be done in parallel
11/15/2018

61. Project 3 part 1: Virtual Memory
Work on vm subdirectory
And addrspace.cc/.h and exception.cc in userprog
Create/manage a backing store (a file called SWAP using the OpenFile class).
Implement a page fault handler with dirty bit handling and a page replacement policy (LRU or second chance)
Design with no implementation for copy-on-write.
Test under various conditions:
One process with an address space larger than physical memory.
Concurrent processes with combined address space larger than physical memory.
11/15/2018

62. Project 3 part 2: File system
Work on filesys subdirectoy.
And change system call handling code in userprog if needed (to use this extended file system).
Extend the size of each file from 4K to 100K+
Few single indirect pointers in i-node.
Extensible file size (not fixed size).
Can add more than 10 files to the directory (currently the disk directory file is a fixed size of 10 entries)
11/15/2018