OS Simulator Solution

Introduction



This set of programming assignments is designed to materialize all of the major operating systems concepts in the CS 446/646 course by allowing you to make design decisions during development of an operating system. These assignments will increase your understanding of operating systems and incorporate common aspects of industry and/or advanced academia.




Over the course of the semester, you will complete one introductory assignment and four simulation assignments. After the completion of the fourth simulation assignment, you will have simulated the core components of a modern day operating system. Each of the assignments build tremendously upon the previous assignment, thus it is advantageous for you to design each assignment with all future assignments in mind. This will signi cantly reduce your workload in the long run.




This document may change throughout the semester and suggestions may be made for any changes one week prior to the assignment due date. This is however at the instructor's discretion.




All of the simulation assignments must be completed using C or C++. All programs require the use of a make le. ALL PROGRAMS MUST RUN AND COMPILE IN THE ECC, OTHERWISE YOUR GRADE WILL RESULT IN A ZERO




Simulator Description



2.1 Expectations




A rubric will be provided for each program. In addition to the rubric, the following will be expected of each program throughout the simulation assignments:



since you will have an overview of all of the programs, it will be worth your time to consider the subsequent phases as you develop the rst program(s); if you have an overlying strategy from the beginning, extending each program will not be di cult




you may work with any number of fellow students to develop your program design, related data structures, algorithmic actions, and so on for each phase. If you do, you must note which students with whom you worked in your upload text on WebCampus; this is for your protection




that said, once you begin coding each phase, you may not discuss, or work, with anyone on your programming, strategy(s), debugging, and so on; it will behoove you to make sure you have a high-quality design developed prior to beginning your coding process




all programs must be eminently readable, meaning any reasonably competent programmer should be able to sit down, look at your code, and know how it works in a few minutes. This does not mean a large number of comments are necessary; your code itself should read clearly. You are also required to follow a documentation format in your code. If you would like an example on documentation, search "code documentation" in a search engine. You will be graded on the readability of your code and di culty in reading your code may result in a reduced grade




the program must demonstrate all the software development practices expected of a 400- (or 600-) level course. For example, all potential le failures must be resolved elegantly, any screen presentation must be of high quality, any data structures or management must demonstrate high quality, supporting actions and components must demonstrate e ective modularity with the use of functions, and so on. This means your code should be tested for failure and handled accordingly, including informing the user of the errors encountered in your simulator




you may use any I/O libraries or classes as needed, but any other classes must be created by you. In addition, you may use POSIX/pthread operations to manage your I/O operations but you may not use previously created threads such as timer threads (e.g., sleep, usleep, etc.). You may use the C standard template library and C standard string library. Additionally, you are free to use basic error libraries but the errors must be handled by you




for each programming assignment, each student will upload the program les through WebCampus. The le for each student must be tarred and zipped in Linux as speci ed below, and must be able to be unzipped on any of the ECC computers include any and all les necessary for the operation of the program. Any extraneous les such as unnecessary library or data les will be cause for credit reduction. The format for submission is Sim0X <LastNameFirstName.tar.gz where X represents the speci c project number, or as an example, Sim01 SmithJohn.tar.gz




all programs must run on the computers in the ECC with no errors or warnings. To remotely access the ECC (if you wish to test your programs) you can SSH to the ecc, copy your les, and run your les. Instructions for how to do this are listed at: https://source2.cse.unr.edu/w/cse/student_ resources/










2.2 Meta-Data




All assignments will use meta-data to house the information required to run each simulation. The meta acts as the set of instructions for your simulation to run on. The meta-data codes are as follows:




S - Operating System, used with begin and finish




A - Program Application, used with begin and finish P - Process, used with run




I - used with Input operation descriptors such as hard drive, keyboard, scanner




O - used with Output operation descriptors such as hard drive, monitor, projector


M - Memory, used with block, allocate




The meta-data descriptors are as follows:




begin, finish, hard drive, keyboard, scanner, monitor, run, allocate, projector, block




The meta-data will always follow the format:




<META DATA CODE(<META DATA DESCRIPTOR)<NUMBER OF CYCLES




For example, an input keyboard operation that runs for 13 cycles would look like the following:




I(keyboard)13




Below is an example meta-data le:







Start Program Meta-Data Code:



S{begin}0; A{begin}0; P{run}11; P{run}9; P{run}12;



P{run}9; P{run}11; P({run}8; P{run}14; P{run}14; P{run}12;



4 P{run}12; P{run}6; P{run}8; P{run}9; P{run}6; P{run}14;




5 P{run}15; P{run}12; P{run}9; P{run}6; P{run}5; A{finish}0;




6 A{begin}0; P{run}6; P{run}6; P{run}9; P{run}11; P{run}13;




7 P{run}14; P{run}5; P{run}7; P{run}14; P{run}15; P{run}7;




8 P{run}5; P{run}14; P{run}15; P{run}14; P{run}7; P{run}14;




9 P{run}13; P{run}8; P{run}7; A{finish}0; A{begin}0; P{run}6;




P{run}10; P{run}13; P{run}9; P{run}15; P{run}6; P{run}13;



P{run}11; P{run}5; P{run}6; P{run}7; P{run}12; P{run}11;



P{run}6; P{run}8; P{run}10; P{run}5; P{run}8; P{run}9; P{run}7;



A{finish}0; S{finish}0.



End Program Meta-Data Code.









2.3 Con guration



Each assignment will use a con guration le to set up the OS simulation for use. This will specify the various cycle times associated with each computer component, memory, and any other necessary informa-tion required to run the simulation correctly. All cycle times are speci ed in milliseconds. For example, if the hard drive cycle time is 50 ms/cycle and you must run for 5 cycles, the hard drive must run for 250 ms. Log File Path is the name of the new le which will display the output. These will be used by a timer to accurately display timestamps for each OS operation. You must use an onboard clock interface of some kind to manage this, and the precision must be to the microsecond level. The con guration will need to be read in prior to running any processes. The con guration le will be key to setting the constraints under which your simulation will run.







Below is an example con guration le:







Start Simulator Configuration File



2 Version/Phase: 2.0




3 File Path: Test_2e.mdf




4 Projector cycle time {msec}: 25




5 Processor cycle time {msec}: 10




6 Keyboard cycle time {msec}: 50




7 Monitor display time {msec}: 20




8 Scanner cycle time {msec}: 10




9 Hard drive cycle time {msec}: 15




Log: Log to Both



Log File Path: logfile_1.lgf



End Simulator Configuration File



2.4 Running the Simulator




When running the simulator you will be required to input a single con guration le (extension .conf). You will run the simulator from the command line similar to the following:




./sim0X config 1.conf







The name of the assignment must be the simulator number. Many con guration les should be used to test your program, which you may modify for testing purposes as you see t.




2.5 Turning in Assignments




All assignments will be turned into WebCampus. You must submit a zipped .tar.gz archive as speci ed above. Inside the archive there should only be the les required to run the simulator (e.g., all source les, all header les). No resource les are allowed. Late assignments will not be accepted.




Assignment 1



3.1 Description




Assignment 1 tests your knowledge of strings, reading from les, and data structures. This assignment allows you to create a library of functions for use in later projects. Keep in mind that you will be using many of the functions you create in this phase of the simulator in future phases. Assignment 1 is designed as a data structures problem, and is not a part of the o cial simulator.




3.2 Speci cation




You will be given an arbitrary number of con guration les to read into your simulation program. Each con guration le will contain a version number (from 1-4), which will change the content of the con guration le and must be handled accordingly. Along with the con guration les, a number of test meta-data les will be given. You will need to read in the information on each le and display the metrics for them. The grader should be able to easily read your code, and run your program using the commands: make and ./Sim01 <CONFIG FILE. Name your le Sim01 for this assignment and include only the make le and any source or header les in your gzipped archive. Refer to the Expectations Section for how to submit your archive to Webcampus.







For the con guration le you will:




Output all of the cycle times in the format below Log to a le/monitor as speci ed




Read from the meta-data le speci ed




Log to the speci ed le location (ONLY if logging to the le) For the meta-data le you will:




Output each operation and the total time for which it would run (e.g., O(hard drive)5 would run for 5 hard drive cycle time)




Additionally you will be required to:




handle le failures and typos (this includes a missing le, an incorrect le path, a typo in the le name, etc.)




handle meta-data and con guration typos (this includes misspellings in the con guration or meta data le, incorrect characters such as a colon instead of a semi-colon, etc.)

correctly identify and handle missing data (such as a missing processor cycle time or a time of 0)




utilize a (set of) data structure(s) to organize information and compute information through the data structure




open and close any les only once (for reading/writing only)




document EVERY function and data structure used throughout the program (anyone should look at your code and be able to read it like a book, you can nd examples of code documentation by running a search on it)




specify the con guration le as a command line argument use a make le




As a reminder, all of the functions created in this assignment will be used for your future assignments and are designed to help you easily transition from understanding data structures to actually applying them in the context of an operating system.




3.3 Example Con guration File







Start Simulator Configuration File



2 Version/Phase: 1.0




3 File Path: Test_1a.mdf




4 Monitor display time {msec}: 20




5 Processor cycle time {msec}: 10




6 Scanner cycle time {msec}: 25




7 Hard drive cycle time {msec}: 15




8 Keyboard cycle time {msec}: 50




9 Memory cycle time {msec}: 30




Projector cycle time {msec}: 10



Log: Log to Both



Log File Path: logfile_1.lgf



End Simulator Configuration File









3.4 Example Input







Start Program Meta-Data Code:



S{begin}0; A{begin}0; P{run}11; M{allocate}2;



O{monitor}7; I{hard drive}8; I{scanner}8; O{projector}20;



4 P{run}6; O{projector}4; M{block}6;




5 I{keyboard}17; M{block}4; O{projector}8; P{run}5; P{run}5;




6 O{hard drive}6; P{run}18; A{finish}0; S{finish}0.




7 End Program Meta-Data Code.










3.5 Example Output







Configuration File Data



2 Monitor = 20 ms/cycle




3 Processor = 10 ms/cycle




4 Scanner = 25 ms/cycle




5 Hard Drive = 15 ms/cycle



Keyboard = 50 ms/cycle



7 Memory = 30 ms/cycle




8 Projector = 10 ms/cycle




9 Logged to: monitor and logfile_1.lgf




10




Meta-Data Metrics



P{run}11 - 110 ms



M{allocate}2 - 60 ms



O{monitor}7 - 140 ms



I{hard drive}8 - 120 ms



I{scanner}8 - 200 ms



O{projector}20 - 500 ms



P{run}6 - 60 ms



O{projector}4 - 100 ms



M{block}6 - 180 ms



I{keyboard}17 - 850 ms



M{block}4 - 120 ms



O{projector}8 - 80 ms



P{run}5 - 50 ms



P{run}5 - 50 ms



O{hard drive}6 - 90 ms



P{run}18 - 180 ms