CS 550 Operating Systems

CS 550 Operating Systems

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
代写CS 550 Operating 代写操作系统程序CS 550 代写C语言程序作业
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.

因为专业，所以值得信赖。如有需要，请加QQ：99515681 或邮箱：[email protected]

微信：codehelp