• Mac Os Mojave
• Mac Os Catalina

Ans1: (a) Stealing or copying a user 's files; writing over another program 's (belonging to another user or to the OS) area in memory; using system resources (CPU, disk space) without proper accounting; causing the printer to mix output by sending data while some other user 's file is printing. View Lab Report - CIS106, Unit 4 Lab Assignment 1, Using Apple Mac OS X.docx from CIS 106 at ECPI University, Virginia Beach. CIS106 Introduction To Operating Systems Unit 4 Lab Report 1: Apple MAC.

• Operating System Assignment Help An operating system can be defined as the computer software that allows the user to execute basic tasks such as file management, handling input and output, controlling devices such as a printer, and disk drives.
• Global Nav Open Menu Global Nav Close Menu; Apple; Shopping Bag +.
• Need MacOS Assignment Help in Australia? We offer reliable MacOS Assignment services by our Machintosh opertaing system expert.

Tuesday/Thursday 1:00-2:30

Pierce 301

Home

Syllabus

Assignments

Resources

Piazza

In-Class Design Review: Tuesday, February 7
Design Due: Friday, February 10 at 5:00PM
Assignment Due: Friday, February 24 at 5:00PM

Objectives

• Be able to write code that meets a specified interface definition.
• Understand how to represent processes in an operating system.
• Design and implement data structures to manage processes and scheduling inan operating system.
• Understand how to implement system calls.
• Understand the theory and practice of process scheduling.

Introduction

This is the first assignment that requires you to work in teams oftwo. This may be difficult if you are accustomed to working alone,but it is essential for the completion of the remaining assignmentsand is a worthwhile skill to develop in any case. These assignmentsare too complex to be done single-handedly, and you will gainvaluable real-world experience from learning to work in a teameffectively.

To begin working together, you and your partner need to pick a teamname, decide on a code base, and then need to set up a shared Gitrepository; all three steps are described in more detail below. Chooseyour code base with care! The assignments are cumulative, and you willhave to live with the consequences of this decision for the remainderof the semester. We suggest that you and your partner resolve conflictsabout things like programming style and naming conventions now in orderto avoid confusion later. Working together on a program can be much moredemanding and frustrating than doing lab work together. (Imagine writinga coherent term paper with someone else!)

The code base you select should be a working OS/161 system with clean,well-commented, bullet-proof synchronization primitives. You and your partnershould share your solutions to the previous assignments (it's good practice tolearn to read and understand someone else's code) and decide what your code basewill be. You are free to choose either partner's code, to merge your solutions,or to use the solution set.

Once you have selected a code base, refer to the section belowfor directions on setting up a shared Git repository.

Picking a team name

For over 20 years, the teams in CS 161 have been named after animals.You and your partner should select the animal that most accuratelyrepresents your excellence. The animal can be real or mythical, butchoose wisely! Good things rarely happen to Team Unambitious Sloth.

Working in teams

There are a number of issues that you and your partner should work out now, whenthings are calm, so you needn't figure them out at 2:00 AM in the heat of themoment.

Naming Conventions

It's a good idea to select some rudimentary protocol for naming global variablesand variables passed as arguments to functions. This way, you can just ask yourpartner to write some function and, while s/he's doing it, you can make calls tothat function in your own code, confident that you have a common namingconvention from which to work. Be consistent in the way you write the names offunctions: given a function called 'my function', one might write its name asmy_function, myFunction, MyFunction, mYfUnCtIoN, ymayUnctionFay, etc. Pick onemodel and stick to it (although we discourage the last two examples).

Git Use

Since you and your partner will be using Git to manage your work, you will needto decide when and how often to commit and push changes. (Advice: early andoften.) Additionally, you should agree upon how much detail to log whencommitting files. Perhaps more importantly, you also need to think about how tomaintain the integrity of the system- what procedures to follow to make sure youcan always pull a working version of some sort from Git, whether or not it's thelatest version, what tests to run on a new version to make sure you haven'tinadvertently broken something, etc.

Clear, explicit Git logs are essential. If you are incommunicado for somereason, it is vital for your partner to be able to reconstruct your design,implementation and debugging process from your Git logs. In general, leavingsomething uncommitted and/or unpushed for a long period of time is dangerous: itmeans that you are undertaking too large a piece of work and have not broken itdown effectively. Once some new code compiles and doesn't break the world, pushit. When you've got a small part working, push it. When you've designedsomething and written a lot of comments, push it. Committing, pushing, andpulling is free. Hours spent hand-merging hundreds of lines of code wastes timeyou'll never get back. The combination of frequent pushes and good, detailedcomments will facilitate more efficient program development.

Use the features of Git to help you. For example, you may want to use tags toidentify when major features are added and when they're stable. The brave ofheart might want to investigate Git branches, which provide completely separatethreads of development (one significant caveat—although branches make lifemuch easier while you're developing within a branch, merging branches togetherlater can be a major headache).

Communication

Nothing replaces good, open communication between partners. The more you candirect that communication to issues of content ('How shall we designsys_execv()?') instead of procedural details ('What do you mean, younever pushed your version of foo.c?'), the more productive your groupwill be.

In your design documents for each assignment, you must identify, at least ingeneral terms, who is responsible for the various parts of your solutions.

If at any time during the course of the semester, you and your partner realizethat you are having difficulty working together, please come speak withProfessor Mickens or one of the teaching fellows. We will work with you to helpyour partnership work more effectively, or in extreme circumstances, we willhelp you find new partners. Do not suffer in silence; please come talk with us.Addressing issues early is practically always better than suffering in silence.

Setting up Your Git Repositories

Before working on this assignment, you and your partner must set up a Gitrepository that will serve as the master repository for both of you for the restof the semester. In the instructions below, we assume that your names areALICE and BOB, and that you've chosen to use ALICE's code.[You are also allowed to use the Assignment 1 solution set instead of your oryour partner's code. Please contact the course staff if you're interested inthis option, but we very much recommend that you use either your or yourpartner's code.]

• ALICE should click on the Github Classroom link for creating the group Github account that she and her partner will use for Assignments 2, 3, and 4.
• That link will allow ALICE to create a new team whose name is the spirit animal for ALICE and BOB. A new team repository will be created; this repository will initially be empty.
• ALICE should follow the directions provided by Github Classroom to 'push an existing repository from the command line;' that existing repository should be her Assignment 1 repository.
• At this point, the team repository has now been initialized.
• BOB should now click on the Github Classroom link for joining a team repository. BOB should join the team created by ALICE.

Now, both ALICE and BOB have access to the teamrepository.

BOB should now do the following:

Now one of you should tag the repository:

The other partner should git pull and ensure that the asst2-starttag got pulled successfully.

Don't forget to configure and build the new tree you're working in (especiallyBOB, since this is an entirely new repository for him).

Assignment Organization

There are three videosthat we consider supplemental to this assignment.Both you and your partner should check them out and make sure you knowthe material covered in them.

Your current OS/161 system has minimal support for running executables --nothing that could be considered a true process. Assignment 2starts the transformation of OS/161 into a true multi-tasking operatingsystem. After the next assignment, it will be capable of running multipleprocesses at once from actual compiled programs stored in your account.These programs will be loaded into OS/161 and executed in user mode bySystem/161; this will occur under the control of your kernel and the commandshell in bin/sh.

First, however, you must implement the interface between user-mode programs('userland') and the kernel. As usual, we provide part of the code you willneed. Your job is to design and build the missing pieces.

You will also be implementing the subsystem that keeps track of the multipletasks you will have in the future. You must decide what data structures you willneed to hold the data pertinent to a 'process' (hint: look at kernel includefiles of your favorite operating system for suggestions, specifically theproc structure.)

The first step is to read and understand the parts of the system thatwe have written for you. Our code can run one user-level C program ata time as long as it doesn't want to do anything but shut the systemdown. We have provided sample user programs that do this (reboot,halt, poweroff), as well as others that make use of featuresyou will be adding in this and future assignments.

So far, all the code you have written for OS/161 has only been run within, andonly been used by, the operating system kernel. In a real operating system, thekernel's main function is to provide support for user-level programs. Mostsuch support is accessed via 'system calls.' We give you one system call,reboot(), which is implemented in the function sys_reboot() inmain.c. In GDB, if you put a breakpoint on sys_reboot and run the'reboot' program, you can use 'backtrace' to see how it got there.

User level programs

Our System/161 simulator can run normal programs compiled from C. The programsare compiled with a cross-compiler, os161-gcc. This compiler runs onthe host machine and produces MIPS executables; it is the same compiler used tocompile the OS/161 kernel. To create new user programs, you will need to editthe Makefile in bin, sbin, or testbin (depending onwhere you put your programs) and then create a directory similar to those thatalready exist. Use an existing program and its Makefile as a template.

Design

Beginning with this assignment, please note that your design documentsbecome an important part of the work you submit. The design documents shouldclearly reflect the development of your solution. They should not merely explainwhat you programmed. If you try to code first and design later, or even if youdesign hastily and rush into coding, you will most certainly end up in asoftware 'tar pit'. Don't do it! Work with your partner to plan everything youwill do. Don't even think about coding until you can precisely explain to eachother what problems you need to solve and how the pieces relate to each other.

Note that it can often be hard to write (or talk) about new software design --you are facing problems that you have not seen before, and therefore evenfinding terminology to describe your ideas can be difficult. There is no magicsolution to this problem; but it gets easier with practice. The important thingis to go ahead and try. Always try to describe your ideas and designs tosomeone else (we suggest your partner; roommates seem to have a low tolerancefor this sort of thing). In order to reach an understanding, you may have toinvent terminology and notation - this is fine (just be sure to explain it toyour TF in your design document). If you do this, by the time you havecompleted your design, you will find that you have the ability to efficientlydiscuss problems that you have never seen before. Why do you think that CS isfilled with so much jargon?

To help you get started, we have provided the following questions as a guide forreading through the code. We recommend that you divide up the code and have eachpartner answer questions for different modules. After reading the code andanswering questions, get together and exchange summations of the code you eachreviewed. Once you have done this, you should be ready to discuss strategy fordesigning your code for this assignment.

Code walk-through (10 points)

Please write up and hand in answers to the questions found below.Put them in a text file code_reading.txt, which you should put in anew directory called 'asst2' in the submit/ subdirectory of your OS/161repository, i.e. submit/asst2/code_reading.txt.

The key files that are responsible for the loading and running of user-levelprograms are loadelf.c, runprogram.c, and uio.c,although you may want to add more of your own during this assignment.Understanding these files is the key to getting started with the implementationof multiprogramming. Note that to answer some of the questions, you will haveto look in other files.

kern/syscall/loadelf.c:This file contains the functions responsible for loading an ELF executable fromthe filesystem and into virtual memory space. (ELF is the name of theexecutable format produced by os161-gcc.) Of course, at this point thisvirtual memory space does not provide what is normally meant by virtual memory-- although there is translation between the addresses that executables'believe' they are using and physical addresses, there is no mechanism forproviding more memory than exists physically. We recommend not stressing aboutthis until Assignment 3.

kern/syscall/runprogram.c:This file contains only one function, runprogram(), which isresponsible for running a program from the kernel menu. It is a good base forwriting the execv() system call, but only a base -- when writing yourdesign doc, you should determine what more is required for execv() thatrunprogram() does not concern itself with. Additionally, once you havedesigned your process system, runprogram() should be altered to startprocesses properly within this framework; for example, a program started byrunprogram() should have the standard file descriptors available whileit's running.

kern/lib/uio.c:This file contains functions for moving data between kernel and user space.Knowing when and how to cross this boundary is critical to properly implementinguserlevel programs, so this is a good file to read very carefully. You shouldalso examine the code in kern/vm/copyinout.c.

Questions

1. What are the ELF magic numbers?
2. What is the difference between UIO_USERISPACE and UIO_USERSPACE? When should one use UIO_SYSSPACE instead?
3. Why can the struct uio that is used to read in a segment be allocated on the stack in load_segment() (i.e., where does the memory read actually go)?
4. In runprogram(), why is it important to call vfs_close() before going to usermode?
5. What function forces the processor to switch into usermode? Is this function machine dependent?
6. In what file are copyin and copyout defined? memmove? Why can't copyin and copyout be implemented as simply as memmove?
7. What (briefly) is the purpose of userptr_t?

kern/arch/mips: traps and syscalls

Exceptions are the key to operating systems; they are the mechanism that enablesthe OS to regain control of execution and therefore do its job. You can thinkof exceptions as the interface between the processor and the operating system.When the OS boots, it installs an 'exception handler' (carefully craftedassembly code) at a specific address in memory. When the processor raises anexception, it invokes this exception handler,which sets up a 'trap frame' and calls into theoperating system. Since 'exception' is such an overloaded term in computerscience, operating system lingo for an exception is a 'trap'.Interrupts are exceptions, and more significantly for thisassignment, so are system calls. Specifically, syscall/syscall.chandles traps that happen to be syscalls. Understanding at least the C code inthis directory is key to being a real operating systems junkie, so we highlyrecommend reading through it carefully.

locore/trap.c:mips_trap() is the key function for returning control to the operatingsystem. This is the C function that gets called by the assembly exceptionhandler. enter_new_process() is the key function for returningcontrol touser programs. kill_curthread() is the function for handling brokenuser programs; when the processor is in usermode and hits something it can'thandle (say, a bad instruction), it raises an exception. There's no wayto recover from this, so the OS needs to kill off the process. Part ofthis assignment will be to write a useful version of this function.

syscall/syscall.c:syscall() is the function that delegates the actual work of a systemcall to the kernel function that implements it. Notice that reboot()is the only case currently handled. You will also find a function,enter_forked_process(), which is a stub where you will place your codeto implement the fork() system call. It should get called fromsys_fork().

Questions

1. What is the numerical value of the exception code for a MIPS system call?
2. How many bytes is an instruction in MIPS? (Answer this by reading syscall() carefully, not by looking somewhere else.)
3. Why do you 'probably want to change' the implementation of kill_curthread()?
4. What would be required to implement a system call that took more than 4 arguments?

user/lib/crt0/mips: This is the user program startup code.There's only one file in here, mips-crt0.S, which contains the MIPSassembly code that receives control first when a user-level program is started.It calls the user program's main(). This is the code that yourexecv() implementation will be interfacing to, so be sure to check whatvalues it expects to appear in what registers and so forth.

user/lib/libc: This is the user-level C library. There'sobviously a lot of code here. We don't expect you to read it all, although itmay be instructive in the long run to do so. Job interviewers have an uncannyhabit of asking people to implement standard C library functions on thewhiteboard. For present purposes you need only look at the code that implementsthe user-level side of system calls, which we detail below.

user/lib/libc/unix/errno.c:This is where the global variable errno is defined.

user/lib/libc/arch/mips/syscalls-mips.S:This file contains the machine-dependent code necessary for implementing theuser-level side of MIPS system calls.

syscalls.S:This file is created from syscalls-mips.S at compile time and is the actual fileassembled into the C library. The actual names of the system calls are placedin this file using a script called syscalls/gensyscalls.sh that readsthem from the kernel's header files. This avoids having to make a second listof the system calls. In a real system, typically each system call stub isplaced in its own source file, to allow selectively linking them in. OS/161puts them all together to simplify the makefiles.

Questions

1. What is the purpose of the SYSCALL macro?
2. What is the MIPS instruction that actually triggers a system call?(Answer this by reading the source in this directory, not looking somewhereelse.)
3. After reading syscalls-mips.S and syscall.c, you should be prepared toanswer the following question: OS/161 supports 64-bit values; lseek()takes and returns a 64-bit offset value. Thus, lseek() takes a 32-bit filehandle (arg0), a 64-bit offset (arg1), a 32-bit whence (arg3), and needs toreturn a 64-bit offset value. In void syscall(struct trapframe *tf)where will you find each of the three arguments (in which registers) and howwill you return the 64-bit offset?

Design and Implementation (90 points total; 30 points design, 30 points for functionality, 30 pointsfor clarity and attention to detail)

As directed above, before you begin this assignment, tag your repository asasst2-start.

System calls and exceptions

Implement system calls and exception handling. The full range of system callsthat we think you might want over the course of the semester is listed inkern/include/kern/syscall.h. For this assignment you should implement:

• open, read, write, lseek, close, dup2, chdir, getcwd
• getpid
• fork, execv, waitpid, _exit

It's crucial that your syscalls handle all error conditions gracefully (i.e.,without crashing OS/161.) You should consult the OS/161 man pages included inthe distribution and understand fully the system calls that you must implement.You must return the error codes as decribed in the man pages.

Additionally, your syscalls must return the correct value (in case of success)or error code (in case of failure) as specified in the man pages. Some of thegrading scripts rely on the return of appropriate error codes; adherence to theguidelines is as important as the correctness of the implementation.

The file user/include/unistd.h contains the user-level interfacedefinition of the system calls that you will be writing for OS/161 (includingones you will implement in later assignments). This interface is different fromthat of the kernel functions that you will define to implement these calls. Youneed to design this interface and put it in kern/include/syscall.h. Asyou discovered (ideally) in Assignment 0, the integer codes for the calls aredefined in kern/include/kern/syscall.h.

You need to think about a variety of issues associated with implementing systemcalls. Perhaps the most obvious one is: can two different user-level processesfind themselves runninga system call at the same time? Be sure to argue for or against this, andexplain your final decision in the design document.

open(), read(), write(), lseek(), close(), dup2(), chdir(), and__getcwd()

For any given process, the first file descriptors (0, 1, and 2) are consideredto be standard input (stdin), standard output (stdout), andstandard error (stderr). These file descriptors should start outattached to the console device ('con:'), but your implementation mustallow programs to use dup2() to change them to point elsewhere.

Although these system calls may seem to be tied to the filesystem, in fact,these system calls are really about manipulation of file descriptors, orprocess-specific filesystem state. A large part of this assignment is designingand implementing a system to track this state. Some of this information (such asthe current working directory) is specific only to the process, but others (suchas file offset) is specific to the process and file descriptor. Don't rush thisdesign. Think carefully about the state you need to maintain, how to organizeit, and when and how it has to change.

Note that there is a system call __getcwd() and then a library routinegetcwd(). Once you've written the system call, the library routineshould function correctly.

getpid()

A pid, or process ID, is a unique number that identifies a process. Theimplementation of getpid() is not terribly challenging, butpid allocation and reclamation are the important concepts that you mustimplement. It is not OK for your system to crash because over the lifetimeof its execution you've used up all the pids. Design your pid system;implement all the tasks associated with pid maintenance, and only thenimplement getpid().

fork(), execv(), waitpid(), _exit()

These system calls are probably the most difficult part of the assignment, butalso the most rewarding. They enable multiprogramming and make OS/161 a muchmore useful entity.

fork() is the mechanism for creating new processes. It shouldmake a copy of the invoking process and make sure that the parent andchild processes each observe the correct return value (that is, 0 forthe child and the newly created pid for the parent). You will wantto think carefully through the design of fork() and considerit together with execv() to make sure that each system callis performing the correct functionality.

execv(), although 'only' a system call, is really the heart ofthis assignment. It is responsible for taking newly created processesand make them execute something useful (i.e., something different thanwhat the parent is executing). Essentially, it must replace the existingaddress space with a brand new one for the new executable (created bycalling as_create in the current dumbvm system) andthen run it. While this is similar to starting a process straight outof the kernel (as runprogram() does), it's not quite that simple.Remember that this call is coming out of userspace, into the kernel,and then returning back to userspace. You must manage the memory thattravels across these boundaries very carefully. (Also, notice thatrunprogram() doesn't take an argument vector -- but this mustof course be handled correctly in execv()).

Although it may seem simple at first, waitpid() requires a fair bit ofdesign. Read the specification carefully to understand the semantics, andconsider these semantics from the ground up in your design. You may also wish toconsult the UNIX man page, though keep in mind that you are not required toimplement all the things UNIX waitpid() supports -- nor is the UNIXparent/child model of waiting the only valid or viable possibility.

The implementation of _exit() is intimately connected to theimplementation of waitpid(). They are essentially two halves of the samemechanism. Most of the time, the code for _exit() will be simple andthe code for waitpid() relatively complicated -- but it's perfectlyviable to design it the other way around as well. If you find both are becomingextremely complicated, it may be a sign that you should rethink your design.

A note on errors and error handling of system calls:

The man pages in the OS/161 distribution contain a description of the errorreturn values that you must return. If there are conditions that can happen thatare not listed in the man page, return the most appropriate error code fromkern/include/kern/errno.h. If none seem particularly appropriate,consider adding a new one. If you're adding an error code for a condition forwhich Unix has a standard error code symbol, use the same symbol if possible. Ifnot, feel free to make up your own, but note that error codes should alwaysbegin with E, should not be EOF, etc. Consult Unix man pagesto learn about Unix error codes; on Linux systems man errno will do thetrick.

Note that if you add an error code to src/kern/include/kern/errno.h,you need to add a corresponding error message to the filesrc/kern/include/kern/errmsg.h.

kill_curthread()

Feel free to write kill_curthread() in as simple a manner as possible.Just keep in mind that essentially nothing about the current thread's userspacestate can be trusted if it has suffered a fatal exception -- it must be takenoff the processor in as judicious a manner as possible, but without returningexecution to the user level.

Testing using the shell

In user/bin/sh you will find a simple shell that will allowyou to test your new system call interfaces. When executed, the shellprints a prompt, and allows you to type simple commands to run otherprograms. Each command and its argument list (an array of characterpointers) is passed to the execv() system call, after callingfork() to get a new thread for its execution. The shell alsoallows you to run a job in the background using &. Youcan exit the shell by typing 'exit'.

Under OS/161, once you have the system calls for this assignment, youshould be able to use the shell to execute the following user programsfrom the bin directory: cat, cp, false, pwd, and true. You will also findseveral of the programs in the testbin directory helpful.

Scheduling

Note that you do not need to include discussion of the scheduler in yourinitial design document submission, though if you do we're happy to talk aboutit with you. It is, however, expected in your final design documentsubmission.

Right now, the OS/161 scheduler implements a simple round-robin queue. You willsee in thread.c that the schedule() function is actually blank. The round-robinscheduling comes into effect when hardclock() calls thread_yield() and asubsequent call to thread_switch() pops the current thread on the cpu'srun-queueand takes the next thread off the current cpu's run-queue (FIFO order).As we learned in class, this is probably not the best method for achieving optimalprocessor throughput. For this assignment, you should implement a moreinteresting scheduling algorithm.

You should select a better scheduling algorithm to implement and in your designdocument, explain why you selected it over other schedulers and under whatconditions you would expect it to perform better or worse than the otherscheduling algorithms. Think carefully about what information you will need tomaintain in order to implement your scheduler. Provide an analysis of how youwould conduct a fair and extensive analysis of your scheduling algorithm. Whichworkloads would you run to find and demonstrate the benefits and compromises ofyour scheduler? What parameters are tuneable? Consult some of the test programsin testbin (e.g., add.c, hog.c, farm.c, sink.c, kitchen.c, ps.c) andconsider how you would devise your own benchmark if tasked to do so. After youfinish coding your scheduler implementation, update your design document withany new insights on the performance capabilities and pitfalls inherent in yourimplementation and where there is room for improvement.

For this portion of the assignment it is OK to ignore the multi-corenature of OS/161. Your scheduler can operate on the current cpu'srun-queue (e.g., reshuffle the threads on the current cpu's run-queuebased on some priority metric). The threads on the other core will bereshuffled when your scheduler runs on the other core.

You may want your scheduler to be configurable. For example, for a roundrobin scheduler, it should be possible to specify the time slice. Fora multi-level feedback queuing system, you might want to specify thenumber of queues and/or the time slice for the highest priority queue.

It is OK to have to recompile to change these settings, as with the HZparameter of the default scheduler. And it is OK to require a recompileto switch schedulers. But it shouldn't require editing more than a couple#defines or the kernel config file to make these changes.

In any event, OS/161 should display at bootup which scheduler is in use.

Design Considerations

Here are some additional questions and thoughts to aid in writing yourdesign document. They are not, by any means, meant to be a comprehensivelist of all the issues you will want to consider. You do not need toexplicitly answer or discuss these questions in your design document,but you should at least think about them.

Your system must allow user programs to receive arguments from thecommand line. For example, you should be able to run the followingprogram:which will load the executable file cp, install it as a new process,and execute it. The new process will then find file1 on the disk andcopy it to file2.

Some questions to think about:

Passing arguments from one user program, through the kernel, into anotheruser program, is a bit of a chore. What form does this take in C? Thisis rather tricky, and there are many ways to be led astray. You willprobably find that very detailed pictures and several walk-throughs willbe most helpful.

What primitive operations exist to support the transfer of data to andfrom kernel space? Do you want to implement more on top of these?

How will you determine: (a) the stack pointer initial value; (b) theinitial register contents; (c) the return value; (d) whether you canexec the program at all?

You will need to 'bullet-proof' the OS/161 kernel from user programerrors. There should be nothing a user program can do to crash theoperating system (with the exception of explicitly asking the systemto halt).

What new data structures will you need to manage multiple processes?

What relationships do these new structures have with the rest of the system?

How will you manage file accesses? When the shell invokes the catcommand, and the cat command starts to read file1, what willhappen if another program also tries to read file1? What would youlike to happen?

Design Submission

In class on Tuesday, February 7, we will conduct peer design reviews.You should have a complete first revision of your design complete bythen. Bring two hard copies of that design to class and commit thatdesign to your team repository (in the directory os161/submit/asst2).

During the design review, you will complete a review for another teamand they will complete a review for you.You will then undoubtedly want to update your design.Please do so.Document who your review partners were and include a list of thethings you changed in response to your design review.Commit this updated design to your team repository.

Finally, turn in your design document by putting it in the submit/asst2subdirectory of your OS/161 repository as, e.g., design_document.pdf(the extension can change based on your file type). Yourcode_reading.txt should also be included in the submission. Pleasecommit and push to Github Classroom with a message like 'ASST2: Design Doc Submission'by 5:00pm on Friday, February 10. Your group will be assigned to a TFwho will contact you to set up a meeting to discuss your design. It is importantthat both partners attend this meeting and that it's clear that both partnersunderstand all the pieces of the assignment.

Note: Your design document and the code_reading questions are worth 30% of thegrade for this assignment. The design document should contain:

• A high level description of how you are approaching the problem.
• A detailed description of the implementation (e.g., new structures, why they were created, what they are encapsulating, what problems they solve).
• A discussion of the pros and cons of your approach.
• Alternatives you considered and why you discarded them.

Final Online Submission

Your submission will need to include a number of scripts thatdemonstrate your working solution. For each script requested,

1. Begin recording each script into your submit/asst2 directory:
2. Change into your root directory.and boot into your kernel
3. At the prompt, run the requested tests or programs for your currentscript. When finished, type p /sbin/poweroff <return> to shutdown.
4. End your script session by typing exit or by pressing Ctrl-D.

Your final submission should include the following things:

• Your design document, named design_document.ext. The design document should be updated to reflect the final design of your assignment. Remember that this includes discussion of your scheduler, which was not required for the initial design doc submission.
• A script of OS/161 running the various tt* tests successfully. Name each script ttN.script (e.g., tt2.script)
• A script of the OS/161 shell running various basic commands (cat, cp, pwd) under OS/161. Name each script command_name.script.
• Your sys161.conf file.

Your submission folder should look something like the following:

Once you have added and committed all of your changes, including yourasst2 submit directory, please tag and push your changes to Github Classroom:If you ever need to update your submission tag, you might get the warning'fatal: tag 'asst2-submit' already exists'. If this happens, just run

Finally, you must verify your intended submission isdisplayed on the gradingserver; we will not accept submissions not visible on the grading server.

Congrats! You're done!

Sagely Advice

Before the design doc is due:

1. Meet with your partner. Review the files described above. Separately answer the questions provided. Compare your solutions.
2. Discuss high level implementations of your solutions. Do detailed design in parallel with your partner.
3. Decide which functions you need to change and which structures you may need to create to implement the system calls. Discuss how you will pass arguments from user space to kernel space (and vice versa). Discuss how you will keep track of open files. For which system call is this useful? Discuss how you will keep track of running processes. For which system call is this useful?
4. Discuss how you will implement the execv() system call. How is the argument passing in this function different from that of other system calls?

Before the assignment is due:

1. Carefully divide up the work. execv() might be the single most demanding part of the assignment, but waitpid() is non-trivial as well. Perhaps one of you will implement the basic system calls and the other will focus on process support.
2. For the parts you're assigned, verify that the collaborated design will really work. If something needs to be redesigned, do it now, and run it by your partner.
3. Implement.
4. Test, test, test. Test your partner's code especially.
5. Fix. The wise kernel hacker always schedules copious time for debugging.

On the assignment due date:

1. Push all your final changes to your master repository. Make sure yourpartner has committed and pushed everything as well, and that there are nomerge conflicts. Make sure you have the most up-to-date version of everything.Re-run make on both the kernel and userland to make sure all the last-minutechanges get incorporated.
2. Run the tests and generate scripts. If anything breaks, curse (politely) and repeat step 1.
3. Tag and push your Git repository

Macintosh 'System 1'

A version of the classic Mac OS operating system
Developer	Apple Computer, Inc.
OS family	Macintosh
Source model	Closed source
Released to manufacturing	January 24, 1984; 37 years ago
Latest release	1.1 / December 29, 1984; 36 years ago
Kernel type	Monolithic
License	Proprietary
Succeeded by	System 2
Support status
Archaic, unsupported

The Macintosh 'System 1' is the first version of AppleMacintosh operating system and the beginning of the classic Mac OS series. It was developed for the Motorola 68000microprocessor. System 1 was released on January 24, 1984, along with the Macintosh 128K, the first in the Macintosh family of personal computers. It received one update, 'System 1.1' on December 29, 1984, before being succeeded by System 2.^[1]

Features[edit]

This operating system introduced many features that would appear for years to come, some that still exist in the current macOS, and a few that exist in other graphical operating systems such as Microsoft Windows.

The features of the operating system included the Finder and menu bar. In addition to this, it popularized the graphical user interface and desktop metaphor, which was used under license from Xerox PARC.

Due to the limited amount of random-access memory and the lack of an internal hard disk in the original Macintosh, there was no multitasking with multiple applications, although there were desktop accessories that could run while another application was loaded. Also, items in the Trash were permanently deleted when the computer was shut down or an application was loaded (quitting the Finder).

System 1's total size is about 216 KB and contained six files: System (which includes the desk accessories), Finder, Clipboard, an Imagewriter printer driver, Scrapbook, and Note Pad.^[2] A separate diskette included 'A Guided Tour of Macintosh', which contains tutorial demonstrations of the Macintosh system, running on a modified pre-release version of Finder 1.0, as well as training programs for learning to use the mouse, and the Finder. Also included was a 33-minute audio cassette designed to run alongside the demonstrations, emphasising the disk's purpose as a guided tour.^[3]

Menu bar[edit]

The menu bar was a new and revolutionary part of the OS.^{[citation needed]} Similar to the one found on Lisa OS, the System 1 Finder had five menus: the Apple menu, File, Edit, View, and Special. When in an application, the menus would change to ones defined by the application, but most software retained at least the File and Edit menus.^[4]

While within the Finder, the Apple menu contained the 'About the Finder' information, along with the desktop accessories. 'File' menu items included Open, Eject, and Close. 'Edit' had entries for cutting, copying, and pasting. 'Special' was used for managing the hardware and other system functions, and was always the rightmost entry on the menu bar in the Finder. In System 1, the menu had items related to emptying the Trash, cleaning up the desktop, and disk options. By System 1.1, the menu allowed the user to choose an alternate startup program to be run instead of the Finder at boot time; the feature was replaced in System 7 by the 'Startup Items' folder in the System Folder.^{[citation needed]}

Desk accessories[edit]

System 1 came with multiple desk accessories (DA). These included an Alarm Clock, Calculator, Control Panel, Key Caps, Note Pad, Puzzle, and Scrapbook. A difference between desktop accessories and applications is that multiple desktop accessories could be run at once but only one application could run at a time. Desk accessories could also run on top of an application.

• Alarm Clock — This DA could be used just like an alarm clock, as the computer would beep, and the menu bar would flash when the alarm's set time was reached. It could also be used as an easier way to change/set the time and date on the computer. When opened, it would show the time and date set on the computer.
• Calculator — A basic calculator capable of addition, subtraction, multiplication, and division. It featured the basic 18 buttons for input.
• Control Panel — The control panel was used to adjust some of the settings on the computer. What made the original control panel unique from subsequent Mac OS control panels was the intended absence of any text. This was chosen to demonstrate the graphical user interface. Representation was achieved by using symbols. It could be used to adjust settings such as volume, double click speed, mouse sensitivity, and desktop background. On the Macintosh 128K, Macintosh 512K, and the Macintosh Plus, the screen brightness was controlled by a mechanical adjustment wheel beneath the screen.
• Key Caps — A DA used to show the layout of the original Macintosh keyboard. It showed what happened when normal keys were pressed along with special characters (Command, Shift, Option).
• Note Pad — A note taking DA that would save text entered into it on the floppy disk. Multiple note pages could be written when using the folded corner symbol in the bottom left corner of the note page.
• Puzzle — A basic 1-15 slide puzzle, similar to the picture puzzle found in later versions of the Mac OS.
• Scrapbook — This DA was similar to a cut, copy, and paste library. In it, one could store text selections and photos which could then be transferred to other applications.

See also[edit]

References[edit]

1. ^Mesa, Andy. 'The Early Mac OS'. The Apple Museum. Retrieved 2015-02-15.
2. ^Pogue, David (January 1997). MacWorld Macintosh Secrets 4th Edition - Part 1: System Software Revealed(PDF). Hungry Minds. p. 216.
3. ^'First Versions: Apple Mac OS'. First Versions. Retrieved 14 January 2018.
4. ^Conachey, Andrew. 'Innovative Macintosh System 1'. Low End Mac. Retrieved 2016-08-15.

External links[edit]

Mac Os Mojave

• Macintosh System 1 in your browser – A web-based simulator
• System 1.0 Headquarters — a walkthrough of System 1 with screenshots (from 1998, via archive.org)

Preceded by

System 1 1984

Succeeded by System 2

Mac Os Catalina