Introducing User Programs into Nachos SPARC HW OS Kernel (Solaris) MIPS sim Nachos User Programs Syscalls Machine instructions MIPS instr Nachos calls.

Slides:



Advertisements
Similar presentations
Memory Protection: Kernel and User Address Spaces  Background  Address binding  How memory protection is achieved.
Advertisements

Chapter 3 Process Description and Control
Slide 2-1 Copyright © 2004 Pearson Education, Inc. Operating Systems: A Modern Perspective, Chapter 2 Using the Operating System 2.
File Systems.
Discussion Week 4 TA: Kyle Dewey. Overview Project #1 debriefing System calls Project #2.
Processes CSCI 444/544 Operating Systems Fall 2008.
Memory Management (II)
MInix memory management1 Minix Memory Management. Contiguous memory management. No swapping. A list of holes sorted in memory address order is maintained.
Introduction to Kernel
Advanced OS Chapter 3p2 Sections 3.4 / 3.5. Interrupts These enable software to respond to signals from hardware. The set of instructions to be executed.
6/24/2015B.RamamurthyPage 1 File System B. Ramamurthy.
Process in Unix, Linux and Windows CS-3013 C-term Processes in Unix, Linux, and Windows CS-3013 Operating Systems (Slides include materials from.
CS-502 Fall 2006Processes in Unix, Linux, & Windows 1 Processes in Unix, Linux, and Windows CS502 Operating Systems.
Unix & Windows Processes 1 CS502 Spring 2006 Unix/Windows Processes.
1 Process Description and Control Chapter 3 = Why process? = What is a process? = How to represent processes? = How to control processes?
Processes in Unix, Linux, and Windows CS-502 Fall Processes in Unix, Linux, and Windows CS502 Operating Systems (Slides include materials from Operating.
7/15/2015B.RamamurthyPage 1 File System B. Ramamurthy.
1 User-Level Processes Needed to test the system call you implement The “Noff” format file required –Look at the Makefile in test MIPS “syscall” instruction.
BINA RAMAMURTHY UNIVERSITY AT BUFFALO System Structure and Process Model 5/30/2013 Amrita-UB-MSES
File Systems (1). Readings r Silbershatz et al: 10.1,10.2,
Rensselaer Polytechnic Institute CSCI-4210 – Operating Systems David Goldschmidt, Ph.D.
Nachos Instructional OS: Part 2
Welcome to the World of Nachos CPS 110 Spring 2004 Discussion Session 1.
Process in Unix, Linux, and Windows CS-3013 A-term Processes in Unix, Linux, and Windows CS-3013 Operating Systems (Slides include materials from.
Implementing Processes. Review: Threads vs. Processes 1. The process is a kernel abstraction for an independent executing program. includes at least one.
Today’s Topics Introducing process: the basic mechanism for concurrent programming –Process management related system calls Process creation Process termination.
Exec Function calls Used to begin a processes execution. Accomplished by overwriting process imaged of caller with that of called. Several flavors, use.
File Systems CSCI What is a file? A file is information that is stored on disks or other external media.
ITEC 502 컴퓨터 시스템 및 실습 Chapter 2-1: Process Mi-Jung Choi DPNM Lab. Dept. of CSE, POSTECH.
Project 2: Initial Implementation Notes Tao Yang.
Outline Administrative: –Issues? Objective: –File System Design.
File Systems and Disk Layout. I/O: The Big Picture I/O Bus Memory Bus Processor Cache Main Memory Disk Controller Disk Graphics Controller Network Interface.
System calls for Process management
The Buffer Cache Jeff Chase Duke University.
Files & File system. A Possible File System Layout Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall, Inc. All rights reserved
Operating Systems Process Creation
File Systems. 2 What is a file? A repository for data Is long lasting (until explicitly deleted).
Processes and Virtual Memory
Lecture 10 Page 1 CS 111 Summer 2013 File Systems Control Structures A file is a named collection of information Primary roles of file system: – To store.
Nachos Lecture 2 Xiaorui Sun. Phase 2 You have got one machine (machine package) You have to implements the incomplete OS (userprog package) Run programs.
Process Description and Control Chapter 3. Source Modified slides from Missouri U. of Science and Tech.
Programs and Processes. The Virtual Address Space A typical process VAS space includes: user regions in the lower half V->P mappings specific to each.
THE FILE SYSTEM Files long-term storage RAM short-term storage Programs, data, and text are all stored in files, which is stored on.
File Systems and Disk Layout. I/O: The Big Picture I/O Bus Memory Bus Processor Cache Main Memory Disk Controller Disk Graphics Controller Network Interface.
Project 2: User Programs Abdelmounaam Rezgui Acknowledgment: The content of some slides is partly taken from Josh Wiseman’s presentation.
Nachos Instructional OS: Part 2
1 A Seven-State Process Model. 2 CPU Switch From Process to Process Silberschatz, Galvin, and Gagne  1999.
File Systems.  Issues for OS  Organize files  Directories structure  File types based on different accesses  Sequential, indexed sequential, indexed.
Memory Management Chapter 5 Advanced Operating System.
File System Department of Computer Science Southern Illinois University Edwardsville Spring, 2016 Dr. Hiroshi Fujinoki CS 314.
A process is a program in execution A running system consists of multiple processes – OS processes Processes started by the OS to do “system things” –
Introduction to Kernel
Jonathan Walpole Computer Science Portland State University
Protection of System Resources
Filesystems.
Processes in Unix, Linux, and Windows
System Structure and Process Model
System Structure and Process Model
Processes in Unix, Linux, and Windows
CS510 Operating System Foundations
System Structure B. Ramamurthy.
Processes in Unix, Linux, and Windows
File System B. Ramamurthy B.Ramamurthy 11/27/2018.
System Structure and Process Model
Processes in Unix, Linux, and Windows
Processes in Unix and Windows
Structure of Processes
Lecture Topics: 11/20 HW 7 What happens on a memory reference Traps
Presentation transcript:

Introducing User Programs into Nachos SPARC HW OS Kernel (Solaris) MIPS sim Nachos User Programs Syscalls Machine instructions MIPS instr Nachos calls User Process Internal Nachos thread Conceptually: Nachos thread encapsulates user program, remains the schedulable entity

Nachos Systems Call (Process) userprog/syscall.h Spaceid Exec (char *name, int argc, char** argv, int pipectrl) - Creates a user process by –creating a new address space, –reading the executable file into it, and –creating a new internal thread (via Thread::Fork ) to run it. –To start execution of the child process, the kernel sets up the CPU state for the new process and then calls Machine::Run to start the machine simulator executing the specified program's instructions in the context of the newly created child process.

Nachos Systems Call (Process) userprog/syscall.h Exit (int status) - user process quits with status returned. The kernel handles an Exit system call by –destroying the process data structures and thread(s), –reclaiming any memory assigned to the process, and –arranging to return the exit status value as the result of the Join on this process, if any. Join (Spaceid pid) - called by a process (the joiner) to wait for the termination of the process (the joinee) whose SpaceId is given by the pid argument. –If the joinee is still active, then Join blocks until the joinee exits. When the joinee has exited, Join returns the joinee's exit status to the joiner.

StartProcess(char *filename) { OpenFile *executable = fileSystem->Open(filename); AddrSpace *space; 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(); // set the initial register values space  RestoreState(); // load page table register machine  >Run(); // jump to the user progam ASSERT(FALSE); // machine->Run never returns; // the address space exits // by doing the syscall "exit" }  Exec

ExceptionHandler(ExceptionType which) { int type = machine->ReadRegister(2); if ((which == SyscallException) && (type == SC_Halt)) { DEBUG('a', "Shutdown, initiated by user program.\n"); interrupt->Halt(); } else { printf("Unexpected user mode exception %d %d\n", which, type); ASSERT(FALSE); } SPARC HW OS Kernel MIPS sim Nachos User Programs Syscalls Machine instructions MIPS instr ExceptionHandler Note: system call code must convert user-space addresses to Nachos machine addresses or kernel addresses before they can be dereferenced

AddrSpace::AddrSpace(OpenFile *executable) {... executable->ReadAt((char *)&noffH, sizeof(noffH), 0); if ((noffH.noffMagic != NOFFMAGIC) && (WordToHost(noffH.noffMagic) == NOFFMAGIC)) SwapHeader(&noffH); ASSERT(noffH.noffMagic == NOFFMAGIC); // 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; ASSERT(numPages <= NumPhysPages); // check we're not trying // to run anything too big -- // at least until we have virtual memory

// first, set up the translation 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; pageTable[i].use = FALSE; pageTable[i].dirty = FALSE; pageTable[i].readOnly = FALSE; // if the code segment was entirely on // a separate page, we could set its // pages to be read-only } // zero out the entire address space, to zero the unitialized data segment // and the stack segment bzero(machine->mainMemory, size);

// then, copy in the code and data segments into memory if (noffH.code.size > 0) { DEBUG('a', "Initializing code segment, at 0x%x, size %d\n", noffH.code.virtualAddr, noffH.code.size); executable->ReadAt(&(machine->mainMemory[noffH.code.virtualAddr]), noffH.code.size, noffH.code.inFileAddr); } if (noffH.initData.size > 0) { DEBUG('a', "Initializing data segment, at 0x%x, size %d\n", noffH.initData.virtualAddr, noffH.initData.size); executable-> ReadAt(&(machine->mainMemory [noffH.initData.virtualAddr]), noffH.initData.size, noffH.initData.inFileAddr); }

Non-contiguous VM 0: NumPhysPages - 1: mainMemory pageTable Now: Need to know which frames are free Need to allocate non-contiguously and not based at zero

Nachos File System

Nachos File Syscalls/Operations Create(“zot”); OpenFileId fd; fd = Open(“zot”); Close(fd); char data[bufsize]; Write(data, count, fd); Read(data, count, fd); Limitations: 1. small, fixed-size files and directories 2. single disk with a single directory 3. stream files only: no seek syscall 4. file size is specified at creation time 5. no access control, etc. BitMap FileSystem Directory FileSystem class internal methods: Create(name, size) OpenFile = Open(name) Remove(name) List() A single 10-entry directory stores names and disk locations for all currently existing files. Bitmap indicates whether each disk block is in-use or free. FileSystem data structures reside on-disk, with a copy in memory.

Representing A File in Nachos FileHdr Allocate(...,filesize) length = FileLength() sector = ByteToSector(offset) A file header describes an on-disk file as an ordered sequence of sectors with a length, mapped by a logical-to-physical block map. OpenFile(sector) Read(char* data, bytes) Write(char* data, bytes) OpenFile An OpenFile represents a file in active use, with a seek pointer and read/write primitives for arbitrary byte ranges. once upo n a time /nin a l and far far away,/nlived t he wise and sage wizard. logical block 0 logical block 1 logical block 2 OpenFile* ofd = filesys->Open(“tale”); ofd->Read(data, 10) gives ‘once upon ‘ ofd->Read(data, 10) gives ‘a time/nin ‘ bytes sectors

File Metadata On disk, each file is represented by a FileHdr structure. The FileHdr object is an in-memory copy of this structure. bytes sectors etc. file attributes: may include owner, access control, time of create/modify/access, etc. logical-physical block map (like a translation table) physical block pointers in the block map are sector IDs FileHdr* hdr = new FileHdr(); hdr->FetchFrom(sector) hdr->WriteBack(sector) The FileHdr is a file system “bookeeping” structure that supplements the file data itself: these kinds of structures are called filesystem metadata. A Nachos FileHdr occupies exactly one disk sector. To operate on the file (e.g., to open it), the FileHdr must be read into memory. Any changes to the attributes or block map must be written back to the disk to make them permanent.

Representing Large Files The Nachos FileHdr occupies exactly one disk sector, limiting the maximum file size. inode direct block map (12 entries) indirect block double indirect block sector size = 128 bytes 120 bytes of block map = 30 entries each entry maps a 128-byte sector max file size = 3840 bytes In Unix, the FileHdr (called an index- node or inode) represents large files using a hierarchical block map. Each file system block is a clump of sectors (4KB, 8KB, 16KB). Inodes are 128 bytes, packed into blocks. Each inode has 68 bytes of attributes and 15 block map entries. suppose block size = 8KB 12 direct block map entries in the inode can map 96KB of data. One indirect block (referenced by the inode) can map 16MB of data. One double indirect block pointer in inode maps 2K indirect blocks. maximum file size is 96KB + 16MB + (2K*16MB) +...

Nachos Directories 0 rain: 32 hail: 48 0 wind: 18 snow: 62 directory fileHdr A directory is a set of file names, supporting lookup by symbolic name. Each directory is a file containing a set of mappings from name  FileHdr. sector 32 Directory(entries) sector = Find(name) Add(name, sector) Remove(name) In Nachos, each directory entry is a fixed-size slot with space for a FileNameMaxLen byte name. Entries or slots are found by a linear scan. A directory entry may hold a pointer to another directory, forming a hierarchical name space.

A Nachos Filesystem On Disk sector 0 allocation bitmap file 0 rain: 32 hail: 48 0 wind: 18 snow: 62 once upo n a time /n in a l and far far away, lived th sector 1 directory file Every box in this diagram represents a disk sector. An allocation bitmap file maintains free/allocated state of each physical block; its FileHdr is always stored in sector 0. A directory maintains the name->FileHdr mappings for all existing files; its FileHdr is always stored in sector 1.

Nachos File System Classes OpenFile(sector) Seek(offset) Read(char* data, bytes) Write(char* data, bytes) Directory SynchDisk Disk OpenFile FileHdr FileSystem Directory(entries) sector = Find(name) Add(name, sector) Remove(name) Allocate(...,filesize) length = FileLength() sector = ByteToSector(offset) BitMap Create(name, size) OpenFile = Open(name) Remove(name) List()