DOCSLIB.ORG

Monolithic Kernels and the Unix API

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Monolithic Kernels and the Unix API Monolithic Kernels and the Unix API 1 homework xv6 introduction: due Friday 2 anonymous feedback “It would be really helpful if homework directions were less vague. Things don’t have to be hard and confusing just for the sake of it. it probably is, but I can only make (probably bad) guesses about how it’s vague trying to maintain balance: giving complete homework requirements (without saying “modify line X of file Y ”) not having walls of text that no one reads not copying all the lecture material, etc. into homework writeup 3 homework steps system call implementation: sys_writecount hint in writeup: imitate sys_uptime need a counter for number of writes add writecount to several tables/lists (list of handlers, list of library functions to create, etc.) recommendation: imitate how other system calls are listed create a userspace program that calls writecount recommendation: copy from given programs 4 note on locks some existing code uses acquire/release you do not have to do this only for multiprocessor support …but, copying what’s done for ticks would be correct 5 xv6 context switch and saving user mode kernel mode start trap handler save A’s user regs to kernel stack running A swtch() — switch kernel stacks/kernel registers running B exit trap handler restore B’s user regs from kernel stack 6 where things go in context switch ‘from’ user stack ‘from’ kernel stack ‘to’ kernel stack ‘to’ user stack main’s return addr. saved user registers saved user registers main’s return addr. main’s vars trap return addr. trap return addr. main’s vars … … … … caller-saved registers caller-saved registers swtch arguments swtch arguments swtch return addr. swtch return addr. %esp value saved ebp saved ebp %esp value after just before exception saved ebx saved ebx return-from-exception saved esi saved esi saved edi saved edi last %esp value first %esp value for ‘from’ process for ‘to’ process (saved by swtch) (argument to swtch) 7 where things go in context switch ‘from’ user stack ‘from’ kernel stack ‘to’ kernel stack ‘to’ user stack main’s return addr. saved user registers saved user registers main’s return addr. main’s vars trap return addr. trap return addr. main’s vars … … … … caller-saved registers caller-saved registers swtch arguments swtch arguments swtch return addr. swtch return addr. %esp value saved ebp saved ebp %esp value after just before exception saved ebx saved ebx return-from-exception saved esi saved esi saved edi saved edi last %esp value first %esp value for ‘from’ process for ‘to’ process (saved by swtch) (argument to swtch) 7 (fromsetlidttrap theit to mmu.h):—returnsT_SYSCALL use the to kernelalltraps(= “code0x40 segment”) interrupt to alltrapsmeaning:// Set up restores runa normal in registers kernelinterrupt mode from/traptf,gate thendescriptor returns to. user-mode //befunction- callableistrap (in: from x86.h)1 for usera wrappingtrap modegate via lidt,int0 instructionforinstructionan interrupt gate. (otherwise:(yes,// interrupt code triggers segmentsgate faultclears specifies like privilegedFL_IF ,more instruction)trap thangate leavesthatFL_IF — nothingalone we care about) sets// vectors.S- thesel:interruptCode segmenttrapasm.S descriptorselector tablefor interrupttrap.c/trap handler vector64:// - off: Offset alltraps:in code segmentvoidfor interrupt/trap handler table//pushl- dpl of $0:handlerDescriptor functions...Privilegefor eachtrap(Level interruptstruct- trapframe type *tf) //pushl $64the privilegecall traplevel required{ for software to invoke //jmp alltrapsthis interrupt... /trap gate... explicitly using an int instruction. ...#define SETGATE(gate,iret istrap, sel, off, d) \ write syscall in xv6: interrupt table setup trap.c (run on boot) ... lidt(idt, sizeof(idt)); ... SETGATE(idt[T_SYSCALL], 1, SEG_KCODE<<3, vectors[T_SYSCALL], DPL_USER); ... vectors[T_SYSCALL] — OS function for processor to run set to pointer to assembly function vector64 8 interrupt descriptor table x86’s interrupt descriptor table has an entry for each kind of exception segmentation fault timer expired (“your program ran too long”) divide-by-zero system calls … xv6 sets all the table entries …and they always call the trap() function 9 xv6: struct proc process control block some data structure needed to represent a process called Process Control Block 10 process control block some data structure needed to represent a process called Process Control Block xv6: struct proc 10 current registers/PCprocessinformationthe kernel of IDis process processstack about for (user running?open this and files, process kernel) etc. enum procstatestored { on (pointertoevery identify to) process itsor process waiting?kernel has stack one in systemn kernel stack calls UNUSED,(if EMBRYO, not currently SLEEPING, running)or finished? RUNNABLE, RUNNING, ZOMBIE }; if waiting, ≈ thread’s state waiting for what (chan)? information about address space pgdir — used by processor sz — used by OS only xv6: struct proc struct proc { uint sz; // Size of process memory (bytes) pde_t* pgdir; // Page table char *kstack; // Bottom of kernel stack for this process enum procstate state; // Process state int pid; // Process ID struct proc *parent; // Parent process struct trapframe *tf; // Trap frame for current syscall struct context *context; // swtch() here to run process void *chan; // If non-zero, sleeping on chan int killed; // If non-zero, have been killed struct file *ofile[NOFILE]; // Open files struct inode *cwd; // Current directory char name[16]; // Process name (debugging) }; 11 processinformationthe kernel IDis processstack about for running?open this files, process etc. enum procstate { toevery identify processor process waiting? has one in systemn kernel stack calls UNUSED, EMBRYO, SLEEPING, or finished? RUNNABLE, RUNNING, ZOMBIE }; if waiting, waiting for what (chan)? information about address space pgdir — used by processor sz — used by OS only xv6: struct proc current registers/PC of process (user and kernel) stored on (pointer to) its kernel stack struct proc { uint sz; (if not currently// Size of running)process memory (bytes) pde_t* pgdir; // Page table char *kstack; // Bottom of kernel stack for this process enum procstate state;≈ thread’s// stateProcess state int pid; // Process ID struct proc *parent; // Parent process struct trapframe *tf; // Trap frame for current syscall struct context *context; // swtch() here to run process void *chan; // If non-zero, sleeping on chan int killed; // If non-zero, have been killed struct file *ofile[NOFILE]; // Open files struct inode *cwd; // Current directory char name[16]; // Process name (debugging) }; 11 current registers/PCprocessinformation of IDis process process about (user running?open and files, kernel) etc. enum procstatestored { on (pointerto identify to) itsor process waiting?kernel stack in systemn calls UNUSED,(if EMBRYO, not currently SLEEPING, running)or finished? RUNNABLE, RUNNING, ZOMBIE }; if waiting, ≈ thread’s state waiting for what (chan)? information about address space pgdir — used by processor sz — used by OS only xv6: struct proc the kernel stack for this process every process has one kernel stack struct proc { uint sz; // Size of process memory (bytes) pde_t* pgdir; // Page table char *kstack; // Bottom of kernel stack for this process enum procstate state; // Process state int pid; // Process ID struct proc *parent; // Parent process struct trapframe *tf; // Trap frame for current syscall struct context *context; // swtch() here to run process void *chan; // If non-zero, sleeping on chan int killed; // If non-zero, have been killed struct file *ofile[NOFILE]; // Open files struct inode *cwd; // Current directory char name[16]; // Process name (debugging) }; 11 current registers/PCprocessinformationthe kernel of ID process stack about for (user open this and files, process kernel) etc. stored on (pointertoevery identify to) process its process kernel has stack one in systemn kernel stack calls (if not currently running) ≈ thread’s state information about address space pgdir — used by processor sz — used by OS only xv6: struct proc is process running? or waiting? struct proc {enum procstate { uint sz; UNUSED, EMBRYO,// SLEEPING,Size of processor finished?memory (bytes) pde_t* pgdir; RUNNABLE, RUNNING,// Page ZOMBIEtable if waiting, char *kstack;}; // Bottom of kernel stack for this process enum procstate state; // Process statewaiting for what (chan)? int pid; // Process ID struct proc *parent; // Parent process struct trapframe *tf; // Trap frame for current syscall struct context *context; // swtch() here to run process void *chan; // If non-zero, sleeping on chan int killed; // If non-zero, have been killed struct file *ofile[NOFILE]; // Open files struct inode *cwd; // Current directory char name[16]; // Process name (debugging) }; 11 current registers/PCinformationthe kernel ofis process processstack about for (user running?open this and files, process kernel) etc. enum procstatestored { on (pointerevery to) process itsor waiting?kernel has stack one kernel stack UNUSED,(if EMBRYO, not currently SLEEPING, running)or finished? RUNNABLE, RUNNING, ZOMBIE }; if waiting, ≈ thread’s state waiting for what (chan)? information about address space pgdir — used by processor sz — used by OS only xv6: struct proc process ID to identify process in systemn calls struct proc { uint sz; // Size of process memory (bytes) pde_t* pgdir; // Page table char *kstack; // Bottom of kernel stack for this process enum procstate state; // Process state int pid; // Process ID struct proc *parent; // Parent
Load more

Recommended publications
  • Microkernels in a Bit More Depth • Early Operating Systems Had Very Little Structure • a Strictly Layered Approach Was Promoted by Dijkstra
    Motivation Microkernels In a Bit More Depth Early operating systems had very little structure A strictly layered approach was promoted by Dijkstra THE Operating System [Dij68] COMP9242 2007/S2 Week 4 Later OS (more or less) followed that approach (e.g., Unix). UNSW Such systems are known as monolithic kernels COMP9242 07S2 W04 1 Microkernels COMP9242 07S2 W04 2 Microkernels Issues of Monolithic Kernels Evolution of the Linux Kernel E Advantages: Kernel has access to everything: all optimisations possible all techniques/mechanisms/concepts implementable Kernel can be extended by adding more code, e.g. for: new services support for new harwdare Problems: Widening range of services and applications OS bigger, more complex, slower, more error prone. Need to support same OS on different hardware. Like to support various OS environments. Distribution impossible to provide all services from same (local) kernel. COMP9242 07S2 W04 3 Microkernels COMP9242 07S2 W04 4 Microkernels Approaches to Tackling Complexity Evolution of the Linux Kernel Part 2 A Classical software-engineering approach: modularity Software-engineering study of Linux kernel [SJW+02]: (relatively) small, mostly self-contained components well-defined interfaces between them Looked at size and interdependencies of kernel "modules" enforcement of interfaces "common coupling": interdependency via global variables containment of faults to few modules Analysed development over time (linearised version number) Doesn't work with monolithic kernels: Result 1:
    [Show full text]
  • Building Performance Measurement Tools for the MINIX 3 Operating System
    Building Performance Measurement Tools for the MINIX 3 Operating System Rogier Meurs August 2006 Contents 1 INTRODUCTION 1 1.1 Measuring Performance 1 1.2 MINIX 3 2 2 STATISTICAL PROFILING 3 2.1 Introduction 3 2.2 In Search of a Timer 3 2.2.1 i8259 Timers 3 2.2.2 CMOS Real-Time Clock 3 2.3 High-level Description 4 2.4 Work Done in User-Space 5 2.4.1 The SPROFILE System Call 5 2.5 Work Done in Kernel-Space 5 2.5.1 The SPROF Kernel Call 5 2.5.2 Profiling using the CMOS Timer Interrupt 6 2.6 Work Done at the Application Level 7 2.6.1 Control Tool: profile 7 2.6.2 Analyzing Tool: sprofalyze.pl 7 2.7 What Can and What Cannot be Profiled 8 2.8 Profiling Results 8 2.8.1 High Scoring IPC Functions 8 2.8.2 Interrupt Delay 9 2.8.3 Profiling Runs on Simulator and Other CPU Models 12 2.9 Side-effect of Using the CMOS Clock 12 3 CALL PROFILING 13 3.1 Introduction 13 3.1.1 Compiler-supported Call Profiling 13 3.1.2 Call Paths, Call and Cycle Attribution 13 3.2 High-level Description 14 3.3 Work Done in User-Space 15 3.3.1 The CPROFILE System Call 15 3.4 Work Done in Kernel-Space 16 3.4.1 The PROFBUF and CPROF Kernel Calls 16 3.5 Work Done in Libraries 17 3.5.1 Profiling Using Library Functions 17 3.5.2 The Procentry Library Function 17 3.5.3 The Procexit Library Function 20 3.5.4 The Call Path String 22 3.5.5 Testing Overhead Elimination 23 3.6 Profiling Kernel-Space/User-Space Processes 24 3.6.1 Differences in Announcing and Table Sizes 24 3.6.2 Kernel-Space Issue: Reentrancy 26 3.6.3 Kernel-Space Issue: The Call Path 26 3.7 Work Done at the Application
    [Show full text]
  • Adventures with Illumos
    > Adventures with illumos Peter Tribble Theoretical Astrophysicist Sysadmin (DBA) Technology Tinkerer > Introduction ● Long-time systems administrator ● Many years pointing out bugs in Solaris ● Invited onto beta programs ● Then the OpenSolaris project ● Voted onto OpenSolaris Governing Board ● Along came Oracle... ● illumos emerged from the ashes > key strengths ● ZFS – reliable and easy to manage ● Dtrace – extreme observability ● Zones – lightweight virtualization ● Standards – pretty strict ● Compatibility – decades of heritage ● “Solarishness” > Distributions ● Solaris 11 (OpenSolaris based) ● OpenIndiana – OpenSolaris ● OmniOS – server focus ● SmartOS – Joyent's cloud ● Delphix/Nexenta/+ – storage focus ● Tribblix – one of the small fry ● Quite a few others > Solaris 11 ● IPS packaging ● SPARC and x86 – No 32-bit x86 – No older SPARC (eg Vxxx or SunBlades) ● Unique/key features – Kernel Zones – Encrypted ZFS – VM2 > OpenIndiana ● Direct continuation of OpenSolaris – Warts and all ● IPS packaging ● X86 only (32 and 64 bit) ● General purpose ● JDS desktop ● Generally rather stale > OmniOS ● X86 only ● IPS packaging ● Server focus ● Supported commercial offering ● Stable components can be out of date > XStreamOS ● Modern variant of OpenIndiana ● X86 only ● IPS packaging ● Modern lightweight desktop options ● Extra applications – LibreOffice > SmartOS ● Hypervisor, not general purpose ● 64-bit x86 only ● Basis of Joyent cloud ● No inbuilt packaging, pkgsrc for applications ● Added extra features – KVM guests – Lots of zone features –
    [Show full text]
  • Hardware-Driven Evolution in Storage Software by Zev Weiss A
    Hardware-Driven Evolution in Storage Software by Zev Weiss A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy (Computer Sciences) at the UNIVERSITY OF WISCONSIN–MADISON 2018 Date of final oral examination: June 8, 2018 ii The dissertation is approved by the following members of the Final Oral Committee: Andrea C. Arpaci-Dusseau, Professor, Computer Sciences Remzi H. Arpaci-Dusseau, Professor, Computer Sciences Michael M. Swift, Professor, Computer Sciences Karthikeyan Sankaralingam, Professor, Computer Sciences Johannes Wallmann, Associate Professor, Mead Witter School of Music i © Copyright by Zev Weiss 2018 All Rights Reserved ii To my parents, for their endless support, and my cousin Charlie, one of the kindest people I’ve ever known. iii Acknowledgments I have taken what might be politely called a “scenic route” of sorts through grad school. While Ph.D. students more focused on a rapid graduation turnaround time might find this regrettable, I am glad to have done so, in part because it has afforded me the opportunities to meet and work with so many excellent people along the way. I owe debts of gratitude to a large cast of characters: To my advisors, Andrea and Remzi Arpaci-Dusseau. It is one of the most common pieces of wisdom imparted on incoming grad students that one’s relationship with one’s advisor (or advisors) is perhaps the single most important factor in whether these years of your life will be pleasant or unpleasant, and I feel exceptionally fortunate to have ended up iv with the advisors that I’ve had.
    [Show full text]
  • Wdd-Ebook.Pdf
    The illumos Writing Device Drivers Sun Microsystems, Inc. has intellectual property rights relating to technology embodied in the product that is described in this document. In particular, and without limitation, these intellectual property rights may include one or more U.S. patents or pending patent applications in the U.S. and in other countries. U.S. Government Rights – Commercial software. Government users are subject to the Sun Microsystems, Inc. standard license agreement and applicable provisions of the FAR and its supplements. This distribution may include materials developed by third parties. Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California. UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd. Sun, Sun Microsystems, the Sun logo, the Solaris logo, the Java Coffee Cup logo, docs.sun.com, Java, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. or its subsidiaries in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. The OPEN LOOK and Sun™ Graphical User Interface was developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, which license also covers Sun’s licensees who implement OPEN LOOK GUIs and otherwise comply with Sun’s written license agreements.
    [Show full text]
  • Filesystems HOWTO Filesystems HOWTO Table of Contents Filesystems HOWTO
    Filesystems HOWTO Filesystems HOWTO Table of Contents Filesystems HOWTO..........................................................................................................................................1 Martin Hinner < [email protected]>, http://martin.hinner.info............................................................1 1. Introduction..........................................................................................................................................1 2. Volumes...............................................................................................................................................1 3. DOS FAT 12/16/32, VFAT.................................................................................................................2 4. High Performance FileSystem (HPFS)................................................................................................2 5. New Technology FileSystem (NTFS).................................................................................................2 6. Extended filesystems (Ext, Ext2, Ext3)...............................................................................................2 7. Macintosh Hierarchical Filesystem − HFS..........................................................................................3 8. ISO 9660 − CD−ROM filesystem.......................................................................................................3 9. Other filesystems.................................................................................................................................3
    [Show full text]
  • CS 4414 — Introduction
    CS 4414 — introduction 1 Changelog Changes made in this version not seen in first lecture: 27 Aug 2019: remove mention of department login server being alternative for xv6, though it may be useful for other assignments 1 course webpage https://www.cs.virginia.edu/~cr4bd/4414/F2019/ linked off Collab 2 homeworks there will be programming assignments …mostly in C or C++ possibly one assignment in Python one or two weeks if two weeks “checkpoint” submission after first week two week assignments worth more schedule is aggressive… 3 xv6 some assignments will use xv6, a teaching operating system simplified OS based on an old Unix version built by some people at MIT theoretically actually boots on real 32-bit x86 hardware …and supports multicore! (but we’ll run it only single-core, in an emulator) 4 quizzes there will be online quizzes after each week of lecture …starting this week (due next Tuesday) same interface as CS 3330, but no time limit (haven’t seen it? we’ll talk more on Thursday) quizzes are open notes, open book, open Internet 5 exams midterm and final let us know soon if you can’t make the midterm 6 textbook recommended textbook: Operating Systems: Principles and Practice no required textbook alternative: Operating Systems: Three Easy Pieces (free PDFs!) some topics we’ll cover where this may be primary textbook alternative: Silberchartz (used in previous semesters) full version: Operating System Concepts, Ninth Edition 7 cheating: homeworks don’t homeworks are individual no code from prior semesters no sharing code, pesudocode, detailed descriptions of code no code from Internet/etc., with limited exceptions tiny things solving problems that aren’t point of assignment …credited where used in your code e.g.
    [Show full text]
  • W4118 Operating Systems Logistics
    W4118 Operating Systems I Junfeng Yang References: Modern Operating Systems (3rd edition), Operating Systems Concepts (8th edition), previous W4118, and OS at MIT, Stanford, and UWisc Bad News This is a TOUGH course . “Most difficult” rated by CS alumni Unfamiliar low-level systems programming . C and Assembly . No abstraction, close to hardware Intense . “Should be 6 units instead of 3” … . Most of those struggling in CS lounge or CLIC lab late or possibly overnight were OS students And you have to climb up N floors for lecture! . Or wait 10 minutes for elevator … Good News Not interested in learning OS or low-level systems programming? Don’t have to take this course! . New MS Breadth requirement . Waive if you have taken a similar course More Good News Heavy, but totally worth it . “Most useful after graduating” rated by alumni Works hard good grade We’ll do our best to help you Climbing up N floors is good exercise! Why Study OS? OS = arguably the most fundamental software . We do almost everything with computers through OS By studying OS, you will . Gain a good understanding of OS . Gain a good understanding of the big picture • How do hardware, programming language, compiler, algorithms, OS work together? . Learn some portable tricks Possibly . Land a job at Facebook/Google/Microsoft/VMware/… . Get started in systems research . Apply OS ideas to your research area . … What Will We Learn? OS concepts . What does an OS do? • Abstract hardware: processes, threads, files • Manage resources: CPU scheduling, memory management, file systems OS implementation techniques . How does an OS implement X in general? .
    [Show full text]
  • Introduction to Bioinformatics Introduction to Bioinformatics
    Introduction to Bioinformatics Introduction to Bioinformatics Prof. Dr. Nizamettin AYDIN [email protected] Introduction to Perl http://www3.yildiz.edu.tr/~naydin 1 2 Learning objectives Setting The Technological Scene • After this lecture you should be able to • One of the objectives of this course is.. – to enable students to acquire an understanding of, and understand : ability in, a programming language (Perl, Python) as the – sequence, iteration and selection; main enabler in the development of computer programs in the area of Bioinformatics. – basic building blocks of programming; – three C’s: constants, comments and conditions; • Modern computers are organised around two main – use of variable containers; components: – use of some Perl operators and its pattern-matching technology; – Hardware – Perl input/output – Software – … 3 4 Introduction to the Computing Introduction to the Computing • Computer: electronic genius? • In theory, computer can compute anything – NO! Electronic idiot! • that’s possible to compute – Does exactly what we tell it to, nothing more. – given enough memory and time • All computers, given enough time and memory, • In practice, solving problems involves are capable of computing exactly the same things. computing under constraints. Supercomputer – time Workstation • weather forecast, next frame of animation, ... PDA – cost • cell phone, automotive engine controller, ... = = – power • cell phone, handheld video game, ... 5 6 Copyright 2000 N. AYDIN. All rights reserved. 1 Layers of Technology Layers of Technology • Operating system... – Interacts directly with the hardware – Responsible for ensuring efficient use of hardware resources • Tools... – Softwares that take adavantage of what the operating system has to offer. – Programming languages, databases, editors, interface builders... • Applications... – Most useful category of software – Web browsers, email clients, web servers, word processors, etc..
    [Show full text]
  • Recompiling Minix
    8 RECOMPILING MINIX This chapter is intended for those readers who wish to modify MINIX or its utili- ties. In the following pages we will tell what the various files do and howthe pieces are put together to form the whole. It should be emphasized that if you simply intend to use MINIX as distributed, then you do not have torecompile the system and you do not have toread this chapter.Howev er, ifyou want to makechanges to the core of the operating system itself, for example, to add a device driverfor a streamer tape, then you should read this chapter. 8.1. REBUILDING MINIX ON THE IBM PC Although this section is specifically for IBM PC users, it should also be read carefully by everyone interested in recompiling MINIX.Most of what is said here applies to all versions of MINIX.The sections about other processors mostly discuss the differences between recompiling MINIX on an IBM PC and on another system. The MINIX sources are contained in the following directories, normally all subdi- rectories of /usr/src except for include which goes in /usr/include: center allbox; l l. Directory Contents include The headers used by the SEC. 8.1 REBUILDING MINIX ON THE IBM PC 113 commands (has twosubdirectories) kernel Process, message, and I/O device handling mm The memory manager fs The file system tools Miscellaneous tools and utilities test Test programs lib Libraries (has several subdirectories) commands The utility programs (has manysubdirectories) Some of the directories contain subdirectories. If you are working on a hard disk, be sure that all these directories have been set up, and all files copied there from the dis- tribution diskettes and decompressed and dearchived.
    [Show full text]
  • Linux Assembly HOWTO Linux Assembly HOWTO
    Linux Assembly HOWTO Linux Assembly HOWTO Table of Contents Linux Assembly HOWTO..................................................................................................................................1 Konstantin Boldyshev and François−René Rideau................................................................................1 1.INTRODUCTION................................................................................................................................1 2.DO YOU NEED ASSEMBLY?...........................................................................................................1 3.ASSEMBLERS.....................................................................................................................................1 4.METAPROGRAMMING/MACROPROCESSING............................................................................2 5.CALLING CONVENTIONS................................................................................................................2 6.QUICK START....................................................................................................................................2 7.RESOURCES.......................................................................................................................................2 1. INTRODUCTION...............................................................................................................................2 1.1 Legal Blurb........................................................................................................................................2
    [Show full text]
  • Network Driver for Micro Os Xv6
    NETWORK DRIVER FOR MICRO OS XV6 A Project Presented to the faculty of the Department of Computer Science California State University, Sacramento Submitted in partial satisfaction of the requirements for the degree of MASTER OF SCIENCE in Computer Science by Anmoldeep Singh Sandhu SPRING 2020 © 2020 Anmoldeep Singh Sandhu ALL RIGHTS RESERVED ii NETWORK DRIVER FOR MICRO OS XV6 A Project by Anmoldeep Singh Sandhu Approved by: __________________________________, Committee Chair Dr. Jinsong Ouyang __________________________________, Second Reader Dr. Jingwei Yang ____________________________ Date iii Student: Anmoldeep Singh Sandhu I certify that this student has met the requirements for format contained in the University format manual, and this thesis is suitable for electronic submission to the library. Credit is awarded for the Project. __________________________, Graduate Coordinator ___________________ Dr. Jinsong Ouyang Date Department of Computer Science iv Abstract of NETWORK DRIVER FOR MICRO OS XV6 by Anmoldeep Singh Sandhu The network driver is one of the primary requirements for any operating system. Xv6 is a micro-operating system based on version 6 Unix. The latest version of xv6 does not have support for the ethernet driver or the four-layer UDP/IP model. Our work extends the xv6 operating system to support a functioning network driver with the capability of handling a packet burst. This Project also adds support for UDP/IP and Ethernet protocol to the xv6 operating system. _______________________ Committee Chair Dr. Jinsong Ouyang _____________________ Date v ACKNOWLEDGMENTS I am thankful to Dr. Ouyang for providing me the opportunity to learn new skills in the field of driver development. Dr. Ouyang showed trust in me in carrying out this Project.
    [Show full text]