CS 550代写、代做Operating Systems、C/C++语言代写、c++程序语言调试

日期：2019-09-11 10:15

CS 550 Operating Systems, Fall 2019

Programming Project 1

Out: 9/8/2019, SUN

Due date: 9/28/2019, SAT 23:59:59

There are three parts in this programming project.

• In the first part, you are going to make some small changes to the xv6 code, then build and

run xv6. The goal is for you to get acquainted with the xv6 system.

• In the second part, you will implement a shutdown functionality for xv6. The goal of this

part is to learn how system calls are implemented in modern OSes and how system calls are

invoked from a user program with xv6 (in this case, the “shutdown” command).

• In the third part, you are asked to complete two tasks which help you to practice on using

the process APIs we discussed in class.

The coding of the above three parts accounts for 80 points of the project. The demo Q&A

takes the other 20 points.

1 Baseline source code

For this and all the later projects, you will be working on the baseline code that needs to be

cloned/downloaded from your own private GitHub repository. Please make sure you read this

whole section, as well as the grading guidelines (Section 6), before going to the following link at

the end of this section.

• Go to the link at the end of this section to accept the assignment.

– If you are the first of your team to accept the assignment, you will need to create a team

on GitHub classroom for this project. Your team should be named as “Team #”,

where “#” is the team number of your team. You can get your team number

by looking up the table here: https://bit.ly/2kmjinD. For example, if

your team number is “07”, the your team name on GitHub classroom should be “Team

07”. Failure to follow this rule will lead to 10 points deduction.

– If you are the second of your team to accept the assignment, you just need to simply

join your team which was created by your teammate.

• Sometimes the import process may take a long time. Do not click the “Cancel” button,

which will lead to an empty repository. You can just close the page and come back later.

If you have clicked the “Cancel” button or it already took really long (e.g., more than two

hours), contact the instructor and the TAs so we can delete your repository, and you can

click the assignment link to import again.

• Once the import process finishes, you can clone or download the repository into your computer

and start working

Assignment link: https://classroom.github.com/g/4My2Jgju

1

2 PART I: getting familiar with xv6 (15 points)

You can build and run xv6 using either a CS machine or your own computer.

2.1 Build and run xv6

2.1.1 Using a CS machine

(1) Log into a CS machine (i.e., a local machine or a remote cluster machine).

(2) Clone or download the baseline xv6 code.

(3) Compile and run xv6:

$ make qemu-nox

After the compiling the kernel source and generating the root file system, the Makefile will

start a QEMU VM to run the xv6 kernel image just compiled (you can read the Makefile for

more details). Then you will see the following output (disregard the warning message(s)),

indicating you have successfully compiled and run the xv6 system.

xv6...

cpu0: starting 0

sb: size 1000 nblocks 941 ninodes 200 nlog 30 logstart 2 inodestart 32 bmap start 58

init: starting sh

$

Troubleshooting: if you see the following error message

make: execvp: ./sign.pl: Permission denied

Solve it by running the following command:

chmod ugo+x ./sign.pl

Then

make clean

make qemu-nox

2.1.2 Using your own computer

You will need a Linux distribution that supports GNU C, which is targeted at the x86 architecture

and using ELF binaries.

(1) Install QEMU in your computer. For example, on Ubuntu, just run:

$ sudo apt-get install qemu

(2) Perform Section 2.1.1 step (2).

(3) Open the Makefile in the xv6 source directory, and comment out the following line:

QEMU = ˜zhangy/fs/bin/qemu-system-i386

by putting a “#” at the beginning of the line.

2

(4) Perform Section 2.1.1 step (3).

Now you should have xv6 running. You can play with it to see what it can do. For you to properly

debug your work in the future, the easiest and most effective way is to add tracing messages so

that you can check how your code and the OS work. For this purpose, you will need to know how

to print in user space and how to print in kernel with xv6. The following two tasks (i.e., Section

2.2 and Section 2.3) will help you practice on that.

2.2 Add a new shell command (print messages in user space) (10 points)

Add a new shell command (i.e., a user space program) named “myecho” to xv6. After this

command is added, if doing an ls in the root directory, you will see something like:

$ ls

. 1 1 512

.. 1 1 512

README 2 2 1973

cat 2 3 13636

echo 2 4 12601

forktest 2 5 8205

grep 2 6 15548

init 2 7 13502

kill 2 8 12721

ln 2 9 12627

ls 2 10 15483

mkdir 2 11 12750

rm 2 12 12739

sh 2 13 25383

stressfs 2 14 13721

usertests 2 15 67232

wc 2 16 14242

zombie 2 17 12355

myecho 2 18 12742

console 3 19 0

The second to the last line is the new program. The new command works like echo. But it

prints a fix string (“Print in user space: ”) before the user-supplied string. For example, here

should be the outputs if we run the program three times with different strings supplied:

$ myecho Hello World

Print in user space: Hello World

$ myecho CS 550 Operating Systems

Print in user space: CS 550 Operating Systems

$ myecho

Print in user space:

Note: the system should operatable after boot (i.e., should not freeze).

2.3 Print messages in kernel space (5 points)

When compiling and booting the baseline xv6, the outputs during boot looks like:

xv6...

cpu0: starting 0

3

sb: size 1000 nblocks 941 ninodes 200 nlog 30 logstart 2 inodestart 32 bmap start 58

init: starting sh

$

In this task, add a message “*** Print in kernel space.” just before “cpu0: starting” is printed.

The desired output is:

xv6...

*** print in kernel space.

cpu0: starting 0

sb: size 1000 nblocks 941 ninodes 200 nlog 30 logstart 2 inodestart 32 bmap start 58

init: starting sh

$

Note: the system should operatable after boot (i.e., should not freeze).

4

3 PART II: shutdown commands and system call (30 points)

The original xv6 system doesn’t have a “shutdown” command to properly turn off the machine.

In this part, you are going to add two “shutdown” commands, which essentially do the same thing

- to shut down the machine.

3.1 shutdown command and the system call

The first command you need complete is named “shutdown”, which simply shuts down the machine.

In the baseline code, the file “shutdown.c” provides the implementation of this command.

What you need to do is to complete the corresponding system call and its user space wrapper

routine.

3.2 shutdown2 command and the system call

The first command you need complete is named “shutdown2”, which prints a shutdown message

provided by the user within the system call implementation before shutting down the machine.

In the baseline code, the file “shutdown2.c” provides the implementation of this command.

What you need to do is to complete the corresponding system call and its user space wrapper

routine.

3.3 Requirements and hints

• You implementation should not change the code in shutdown.c and shutdown2.c other than

commenting out the “STUB FUNCS” macro definition to remove the stub function. Failure

to follow this requirement will lead to zero point of this part.

• To shut down the xv6 virtual machine in your system call, you only need two lines of code:

outw(0xB004, 0x0|0x2000);

outw(0x604, 0x0|0x2000);

• Reading and understanding how the existing user commands and the associated system calls

are implemented will be helpful. For example, you can look at how the cat user command

is implemented. The cat user command is implemented in cat.c, in which the system call

open() is called. The actual work of the open() system call is done in the sys open()

function defined in sysfile.c.

• Understanding the mechanism is important. Pay attention to all the related files, which

include assembly files (relax, the related assembly file is very easy to read). You may be

requested to explain how things work in xv6 in exams.

5

4 PART III: programming with process APIs (35 points)

In this part, you are going to develop two programs to practice the usage of POSIX process APIs.

Please note that the programs of this part are not to be part of xv6. Instead, they are conventional

programs which will be compiled using GNU GCC.

4.1 Task 1: pipe - executing commands

Write a program which implements the effect of a three-command pipeline, “cmd-1 | cmd-2

| cmd-3”, where “cmd-i” is the i-th line in the file “cmds”.

The current content in file “cmds” is:

cat Makefile

head -4

wc -l

Therefore, running your program would give us the same result as running “cat Makefile |

head -4 | wc -l’.

Your program should also prints when each child process executes its command and when the

parent process reaps each of the child processes. The output of your program with the current

“cmds” file content should look like:

In the above output, “4” is the result of the command pipeline. Please also note that:

• You can assume each line in the “cmds” file contains at most 63 characters, and has at most

8 tokens.

• Only spaces are use to separate tokens in the “cmds” file.

• One of the exec functions (e.g., execl, execlp, execle, execv, execvp, execvpe) should be

used to execute commands in the child processes. Learning how to use these functions and

choosing a proper one according to your program design is part of this task’s goal.

• You will need to properly redirect standard input/output of each child process to the read-

/write end of each pipe. The dup() or the dup2() functions can help you achieve the

goal.

• Recall what we discuss in the class: properly closing the unused pipe file descriptors is

important.

4.2 Task 2: pipe - synchronizing processes

Write a program which forks three child processes (C1, C2, and C3), and uses pipe to control the

execution order of the child processes based on the user input. Specifically,

6

• If “1” is the input by the users, then the execution order should be: C3 → C2 → C1.

• If “2” is the input by the users, then the execution order should be: C2 → C1 → C3.

• If “3” is the input by the users, then the execution order should be: C3 → C1 → C2.

Your program should also prints when each child process executes and when the parent process

reaps each of the child processes. For example, the output of your program should look like:

One key hint (also a reminder of our class discussion): the property used to sync related processes

is that a process reading an empty pipe blocks until something is written to the pipe.

A few tips for completing the project:

• “make clean” allows you to compile everything from scratch.

• Start early and let us know if you have any problems/questions.

• Check in your code to your private GitHub repository regularly as you work on the project,

so that we can monitor the project progress.

• You can use either git command line or the GitHub web interface for code check-in. But

the former is more convenient and professional.

7

5 Submit your work

A submission link be available on the MyCourses website. Once your team’s code in your

GitHub private repository is ready for grading, at least one member of your team will

need submit a file named “DONE”, which minimally contains names and B-numbers

of your team members, to that link. Additionally, you can include the following info in this

file:

• The status of your implementation (especially, if not fully complete).

• A description of how your code works, if that is not completely clear by reading the code

(note that this should not be necessary, ideally your code should be self-documenting).

• Possibly a log of test cases which work and which don’t work.

• Any other material you believe is relevant to the grading of your project.

Suggestion: Test your code thoroughly on a CS machine before submitting.

6 Grading

The following are the general grading guidelines for this and all future projects.

(1) The code in your repository will not be graded until a “DONE” file is submitted

to MyCourses.

(2) The submission time of the “DONE” file shown on the MC system will be used to determine

if your submission is on time or to calculate the number of late days. Late penalty is 10% of

the points scored for each of the first two days late, and 20% for each of the days thereafter.

(3) The naming of your team should follow the guideline stated at the beginning of this document,

otherwise 10 points off.

(4) If you are to compile and run the xv6 system on the department’s remote cluster, remember

to use baseline xv6 source code provided by our GitHub classroom. Compiling and running

xv6 source code downloaded elsewhere can cause 100% CPU utilization on QEMU.

Removing the patch code from the baseline code will also cause the same problem. So make

sure you understand the code before deleting them.

If you are reported by the system administrator to be running QEMU with 100% CPU utilization

on QEMU, 10 points off.

(5) If the submitted patch cannot successfully patched to the baseline source code, or the patched

code does not compile:

1 TA will try to fix the problem (for no more than 3 minutes);

2 if (problem solved)

3 1%-10% points off (based on how complex the fix is, TA’s discretion);

4 else

5 TA may contact the student by email or schedule a demo to fix the problem;

6 if (problem solved)

8

7 11%-20% points off (based on how complex the fix is, TA’s discretion);

8 else

9 All points off;

So in the case that TA contacts you to fix a problem, please respond to TA’s email promptly

or show up at the demo appointment on time; otherwise the line 9 above will be effective.

(6) If the code is not working as required in the project spec, the TA should take points based on

the assigned full points of the task and the actual problem.

(7) Lastly but not the least, stick to the collaboration policy stated in the syllabus: you may

discuss with you fellow students, but code should absolutely be kept private. Any kind of

cheating will result in zero point on the project, and further reporting.

9